7

IIS Web サーバーへの HTTP 接続を確立し、Transfer-Encoding: チャンクを使用してエンコードされたデータを含む POST 要求を送信しています。これを行うと、IIS は単純に接続を閉じます。エラー メッセージやステータス コードは表示されません。HTTP 1.1 仕様によると、

すべての HTTP/1.1 アプリケーションは、「チャンクされた」転送コーディングを受信して​​デコードできなければなりません (MUST)。

そのため、（a）そのエンコーディングを処理していない理由と（b）ステータスコードを返していない理由がわかりません。Transfer-Encoding ではなく Content-Length を送信するようにリクエストを変更すると、クエリは成功しますが、常に可能とは限りません。

Apache に対して同じことを試みると、「411 長さが必要です」というステータスと、「chunked Transfer-Encoding は禁止されています」というメッセージが表示されます。

これらのサーバーがこのエンコーディングをサポートしていないのはなぜですか?

4

5 に答える 5

8

クライアントを見てください。

IIS と Apache の両方が、チャンク転送エンコードを使用した POST 要求をサポートしています。これは、 curl ユーティリティを使用して確認できます。

curl <upload-url> --form "upfile=@<local_file>" --header "Transfer-Encoding: chunked"

Wiresharkを使用して転送がチャンク化されていることを確認する

于 2009-07-30T19:26:30.560 に答える
4

私の理解では、チャンク エンコーディングは HTTP 応答でのみ使用できます。チャンクされたリクエスト ボディは、1.0 サーバーと互換性がないという特性を持ちます。いずれにせよ、ユーザー エージェントは、サーバーが 1.0 サーバーであることを、リクエストを送信するまで知ることができません。

しかし、ドキュメントからは不明確であることに同意します。

于 2008-12-03T21:13:32.867 に答える
3

それは双方向に行きます。画像を2MB++でphotobucketにアップロードして記録してみてください。アップローダーは、Apacheサーバーにチャンクでアップロードします。

于 2011-12-21T19:55:03.713 に答える
-1

私の唯一の推測は、セキュリティ上の懸念から実装しなかったということです。単純な解決策では、終了しない複数のチャンク転送を開始することで、DOS 攻撃を簡単に仕掛けることができます。また、DOS 攻撃を説明できる複雑なソリューションは、おそらく努力する価値はありません。

もちろん、私は Apache や IIS について話すことはできませんが、Apache チームに直接連絡できるかもしれません: http://httpd.apache.org/bug_report.html

チャンクエンコーディングは応答としてのみ使用できると常に思っていたMarkRに同意しますが、ドキュメントでは、要求または応答で使用できるように聞こえます.

于 2008-12-03T21:22:11.103 に答える