我正在尝试使用Wget将 HTML(包含在文件中)发布到 URL,如下所示:
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(超文本传输协议 -- HTTP/1.1)的第 8.2.3 节,看起来这是可能的:
如果请求消息不包含具有“100-继续”期望的 Expect 请求头字段,则源服务器不应发送 100(继续)响应,并且如果此类请求来自HTTP/1.0(或更早版本)客户端。此规则有一个例外:为了与 RFC 2068 兼容,服务器可以发送 100(继续)状态以响应 HTTP/1.1 PUT 或 POST 请求,该请求不包含带有“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.