IISがチャンク転送エンコードをサポートしないのはなぜですか?
-
19-08-2019 - |
質問
IIS WebサーバーへのHTTP接続を確立し、Transfer-Encoding:chunkedを使用してエンコードされたデータでPOST要求を送信しています。これを行うと、IISは単純に接続を閉じ、エラーメッセージやステータスコードは表示されません。 HTTP 1.1仕様、
すべてのHTTP / 1.1アプリケーションは、<!> quot; chunked <!> quot;を受信およびデコードできなければなりません。転送コーディング
そのため、(a)そのエンコーディングを処理しない理由と(b)ステータスコードを返送しない理由がわかりません。 Transfer-EncodingではなくContent-Lengthを送信するようにリクエストを変更した場合、クエリは成功しますが、それが常に可能であるとは限りません。
Apacheに対して同じことを試みると、<!> quot; 411 Length required <!> quot;が返されます。ステータスと<!> quot; chunked Transfer-Encoding forbidden <!> quot;というメッセージ。
これらのサーバーがこのエンコードをサポートしないのはなぜですか?
解決
私の理解では、チャンクエンコーディングはHTTP応答でのみ使用できます。チャンク化されたリクエスト本文には、1.0サーバーと互換性がないという特性があります。いずれにしても、ユーザーエージェントは、リクエストを送信するまでサーバーが1.0サーバーであることを知ることはできません。
しかし、ドキュメンテーションからは明確でないことに同意します。
他のヒント
クライアントを見てください。
IISの両方<!> amp; Apacheは、チャンク転送エンコードを使用したPOST要求をサポートします。これは curlユーティリティを使用して確認できます。
curl <upload-url> --form "upfile=@<local_file>" --header "Transfer-Encoding: chunked"
を使用して、転送がチャンク化されていることを確認します。 それは両方の方向に行きます。画像2MB ++をphotobucketにアップロードして記録してみてください。アップローダーは、Apacheサーバーにチャンクされてアップロードします。
私の唯一の推測は、彼らがセキュリティの懸念からそれを実装しなかったということです。単純なソリューションでは、終了しない複数のチャンク転送を開始することにより、DOS攻撃を簡単に設定できます。また、DOS攻撃を説明できる複雑なソリューションは、おそらく努力する価値はありません。
もちろん、ApacheやIISについて話すことはできませんが、Apacheチームに直接連絡することはできますが、 http://httpd.apache.org/bug_report.html
MarkRには、チャンクエンコーディングは応答としてのみ使用できると常に考えていましたが、ドキュメントでは、要求または応答で使用できるように聞こえることは確かです。
このコマンドは私を助けてくれました!
C:\ Windows \ System32 \ Inetsrv \ Appcmd.exe set config -section:httpCompression
-[name = 'gzip']。staticCompressionLevel:9-[name = 'gzip']。dynamicCompressionLevel:4
私の一日を救った...それが私のような人を助けることを願っています!