爲什麼IIS不支持分塊傳輸編碼？

我正在與IIS Web服務器建立HTTP連接，併發送帶有使用Transfer-Encoding編碼的數據的POST請求：分塊。當我這樣做時，IIS只是關閉連接，沒有錯誤消息或狀態碼。按照HTTP 1.1 spec，爲什麼IIS不支持分塊傳輸編碼？

所有HTTP/1.1應用程序必須能夠接收和解碼的「分塊」傳輸編碼

所以我不明白爲什麼它（一）不處理該編碼和（b）它不發送狀態碼。如果我更改發送Content-Length而不是Transfer-Encoding的請求，則查詢成功，但這並非總是可行。

當我對Apache嘗試同樣的事情時，我得到一個「411 Length Required」狀態和一條消息，表示「chunked Transfer-Encoding forbidden」。

爲什麼這些服務器不支持這種編碼？

來源

2008-12-03 Graeme Perrow

我的理解是分塊編碼只能用在HTTP響應中。分塊的請求體將具有與1.0服務器不兼容的屬性，並且在任何情況下，在用戶代理已經發送請求之前，沒有辦法知道服務器是1.0服務器。

但我同意從文檔不清楚。

來源

2008-12-03 21:13:32 MarkR

客戶端可以通過發送HEAD請求等來詢問服務器。閱讀RFC 2616第3.6節指出，服務器在收到它不理解的傳輸編碼頭時必須發送501響應。 3.6.1節說，所有HTTP 1.1應用程序必須能夠接收和解碼分塊傳輸編碼。所以對我來說似乎很清楚 - 客戶端到服務器的通信可以被分塊。常見的情況是文件上傳。 – Cheeso 2009-07-06 14:49:37

原始海報沒有提及它們使用的是哪個版本的IIS，但IIS 7明確支持傳入的分塊數據 - 我有一個C++應用程序將請求作爲分塊數據發送到IIS 7，沒有任何問題 – 2010-11-30 18:43:34

我認爲你不正確。服務器和客戶端應該支持分塊（這並不意味着它們可以）。你認爲不兼容會導致無效，因爲任何支持http1.1的客戶端也應該知道如何與http1.0服務器通信。請參閱：http://www.jmarshall.com/easy/http/#http1.1s3和：http://www.atnan.com/2008/8/8/transfer-encoding-chunked-chunky-http和：http ：//www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6（也可參閱第3.6.1節） – 2011-02-17 23:58:03

-1

我唯一的猜測是他們沒有實現它出於安全考慮。在一個天真的解決方案中，通過啓動多個永不結束的分塊傳輸很容易設置DOS攻擊。而一個能夠解釋DOS攻擊的複雜解決方案可能是不值得的。

當然我不能爲Apache或IIS可言，您可以直接雖然到Apache團隊聯繫：http://httpd.apache.org/bug_report.html

我MarkR，我一直以爲塊編碼只能作爲一個部門的迴應同意，但文檔確實使它聽起來像可以用於請求或響應。

來源

2008-12-03 21:22:11 grieve

看看你的客戶。

IIS & Apache支持使用分塊傳輸編碼的POST請求。您可以使用curl utility驗證這一點：

curl <upload-url> --form "[email protected]<local_file>" --header "Transfer-Encoding: chunked"

驗證傳輸使用Wireshark

來源

2009-07-30 19:26:30 rupello

它是雙向的分塊。嘗試上傳一張圖片2MB ++到photobucket並記錄下來。他們的上傳器上傳到他們的apache服務器。

來源

2011-12-21 19:55:03

-1

這個命令來救我！

C：\ Windows \ System32下\ INETSRV \ Appcmd.exe的設置配置-section：httpCompression
- [名稱= '的gzip'] staticCompressionLevel：9 - [名稱= '的gzip'] dynamicCompressionLevel：4

救了我一天...希望它能幫助像我這樣的人！

來源

2015-07-30 15:03:59

爲什麼IIS不支持分塊傳輸編碼？

回答

相關問題