次のようなWgetを使用して、HTML(ファイルに含まれている)をURLにPOSTしようとしています。
wget -O- --debug
--header=Content-Type:text/html
--post-file=index.html
http://localhost/www/encoder.ashx
HTMLが投稿されるURLは、ASP.NETを使用して実装されたWebアプリケーションのエンドポイントです。サーバーは100(続行)応答で応答し、Wgetは次に続く実際の応答を続行するのではなく、単にそのトラックで停止します。
Wgetはどういうわけか100(続行)応答を処理するように指示できますか、それともこれはツールのよく知られた制限ですか?
ノート:
Wgetがヘッダーを送信しないことに気付いた
Expect: 100-Continue
ので、技術的にはサーバーが100(続行)応答を発行するべきではありません。更新:RFC 2616(Hypertext Transfer Protocol-HTTP / 1.1)の§8.2.3に従って 、 これは可能であるように見えます:
オリジンサーバーは、リクエストメッセージに「100-continue」期待値のExpect request-headerフィールドが含まれていない場合、100(Continue)応答を送信しないでください。また、そのようなリクエストがHTTP / 1.0(またはそれ以前)のクライアント。このルールには例外があります。RFC2068との互換性のために、サーバーは、「100-継続」期待。この例外は、宣言されていない100(続行)ステータスの待機に関連するクライアント処理の遅延を最小限に抑えることを目的としており、HTTP / 1.1要求にのみ適用され、他のHTTPバージョン値を持つ要求には適用されません。
cURLはそのようなトランザクションに問題はありません。ヘッダーを送信
Expect: 100-Continue
し、実際のヘッダーに100(続行)応答を続けます。
詳細については、上記の呼び出しからのトランザクションの完全なデバッグトレースを次に示します。
Setting --post-file (postfile) to index.html
Setting --header (header) to Content-Type:text/html
DEBUG output created by Wget 1.10 on Windows.
--13:29:17-- http://localhost/www/encoder.ashx
=> `-'
Resolving localhost... seconds 0.00, 127.0.0.1
Caching localhost => 127.0.0.1
Connecting to localhost|127.0.0.1|:80... seconds 0.00, connected.
Created socket 296.
Releasing 0x01621a10 (new refcount 1).
---request begin---
POST /www/encoder.ashx HTTP/1.0
User-Agent: Wget/1.10
Accept: */*
Host: localhost
Connection: Keep-Alive
Content-Type: text/html
Content-Length: 30984
---request end---
[writing POST file index.html ... done]
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 100 Continue
Server: ASP.NET Development Server/9.0.0.0
Date: Wed, 24 Sep 2008 11:29:17 GMT
Content-Length: 0
---response end---
100 Continue
Closed fd 296
13:29:17 ERROR 100: Continue.