2011-08-08 55 views
1

我正在嘗試編寫一個程序來將HTTP請求與其相應的響應進行匹配。似乎對於大多數場景(當傳輸是完全有序的,甚至當傳輸沒有時,通過使用TCP序列號),一切正常。將HTTP響應與其相應的HTTP管道請求進行匹配

我發現的唯一問題是當我有流水線請求時。之後,我收到了幾個回覆,但我不知道哪些數據包是特定請求的答案,哪些不是。我在另一篇文章中看到,響應將按順序進行,將此屬性與Content-Length字段的信息結合似乎是一種解決方案。問題是內容長度不是必填字段,所以我不確定我是否可以始終依賴該字段。

有誰知道如何支持此功能的網絡瀏覽器(順便說一句,不是大多數人)實際上做到了嗎?

回答

2

有關身體長度的信息必須出現在標題中。它並不總是在'內容長度'中。爲了解決全部問題,你將不得不學習相關的RFC 2616最引人注目的是第4.4條處理不同的頭從RFC 2616

一些更相關的規則:

當流水線:
一服務器必須按照收到請求的順序發送它們對這些請求的響應。

從9.2
如果沒有響應體包括,響應必須包含的「0」的字段值內容長度字段。

從10.2.7 206部分內容
的響應必須包含....要麼一個Content-Range頭部字段...或者多部分/字節範圍 內容類型包括對每個部分內容範圍字段。

從14.13 Content-Length的
應用程序應使用此字段,以指示所述消息體的轉印長度,除非這是由規則4.4節中禁止。

+0

非常感謝埃迪!它非常有用。 – Javier

+1

對於像我這樣的人需要流水線時的行爲來源,它在_RFC 2616,8.1.2.2 Pipelining_中。 – Sisyphus

1

當前回覆有點舊。需要刷新。

新的HTTP 1.1 RFC是RFC 7230。幷包含有關解析郵件大小的更精確信息。

檢測的消息的大小是相當複雜的。您可以有Content-lengthTransfer-Encoding: chunked或兩者都有,或者沒有。還有一些特殊的代碼,如100 Continue可能會改變這一切。

第一個鏈接包含7個條目,應按正確的順序檢查以猜測正確的大小。

正如上一個鏈接所述,未能檢測到正確的消息長度可能導致HTTP走私(分裂,緩存中毒)問題。

流水線支持是大多數走私問題的根源。如果你想實現它,你應該真正關心整個RFC7230文檔。