這個HTTP頭是錯誤的嗎？

我想寫一個torrent下載器，並且需要弄清楚如何聯繫跟蹤器。我使用Fiddler2程序攔截從Vuze發送給它的跟蹤器的跟蹤器請求。這個HTTP頭是錯誤的嗎？

在發送的消息（如下所示）中，Connection標頭聲明瞭兩次不同的值。

這是Connection頭的正確用法嗎？ Connection：keep-alive是做什麼的？

GET /announce?info_hash=0Z%22...&azver=3&azas=12576 HTTP/1.1 
User-Agent: Azureus 4.7.0.2;Windows 7;Java 1.6.0_31 
Connection: close 
Accept-Encoding: gzip 
Host: tracker.update.vuze.com:6969 
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 
Connection: keep-alive

來源

2012-07-13 brnby

從RFC2616第4.2節：當且僅當該頭字段整個字段值被定義爲

多幅具有相同字段名的消息的報頭字段可以是在消息本以逗號分隔的列表[即＃（值）]。它必須可以通過將每個後續字段值附加到第一個，每個分隔的一個「字段名稱：字段值」對，而不更改消息的語義，可以將多個標題字段組合到一個「逗號。因此，接收到字段名相同的標題字段的順序對於組合字段值的解釋有意義，因此當轉發消息時，代理不得更改這些字段值的順序。

編輯：

據14.10節，連接是這樣的字段名，所以具有多個連接頭在技術上是正確。

從14.10開始，連接標題的語法生成是Connection = "Connection" ":" 1#(connection-token)，所以一個或多個逗號分隔標記是有效。

但實際上，可能會忽略第二個連接標頭，因此一旦發送響應，Web服務器將期望關閉底層TCP連接。

對於HTTP 1.1，默認模式是讓服務器爲後續請求保持打開底層TCP連接，儘管許多服務器會限制在關閉連接之前發出的請求總數。

來源

2012-07-13 19:43:12

你錯了，連接頭像被定義爲逗號分隔列表。 – 2013-11-18 01:30:50

謝謝。你是對的;我已經根據RFC中的語法生成澄清了我的答案。 – 2013-11-28 02:39:23

奇怪的是它有2個連接頭字段。我認爲你只能期望一個非確定性的行爲，因爲這種情況的處理完全取決於Web服務器的實現。它可能會結束與任何2（比方說）存儲字段的散列映射。

基本上，保持活動意味着允許瀏覽器保持與服務器的連接並保持檢索圖像，腳本。通常情況並非如此。通常情況下，請求被給予響應後，與Web服務器的連接關閉。

來源

2012-07-13 19:36:08 Razvan

Connection: Close

表示請求完成後關閉連接。

Connection: keep-alive

表示保持連接爲未來請求打開。

您應該只有一個連接參數。

因此，HTTP頭是不正確的。

來源

2012-07-13 19:37:30

HTTP 1.1允許多個連接標頭。多個這樣的標題的語義被定義爲與用逗號將所有值連接在一起的單個標題相同，例如，

Connection: close 
Connection: keep-alive

是一樣的：

Connection: close,keep-alive

所以從技術上講，這些頭都很好。但是，我會預測，如果沒有做一些實驗，那裏會有很多服務器（特別是沒有經過很好測試的服務器，比如洪流跟蹤器），他們會忽略這些頭文件中的任何一個。

現在，更深層次的問題是「保持活力」是一些http 1.0擴展名，並且與「close」相矛盾，所以我猜這個組合只是torrent客戶端中的一個bug。我想大多數追蹤者不會允許永久連接，但是，我認爲下注方式只能有一個「連接：關閉」標題。

來源

2013-11-18 01:35:22

這個HTTP頭是錯誤的嗎？

回答

相關問題