我们是否需要“期望：100-继续”？ xfire 请求标头中的标头？
我发现apache xfire在其post header中添加了一个head参数：
POST /testservice/services/TestService1.1 HTTP/1.1
SOAPAction：“testAPI”内容类型：text/xml；字符集=UTF-8
用户代理：Mozilla/4.0（兼容；MSIE 6.0；Windows NT 5.0；XFire 客户端 +http://xfire.codehaus.org）
主机：192.168.10.111:9082
预期：100-继续
这个期望：100-继续会使 xfire 客户端与其端点服务器之间的往返调用有点浪费，因为它将再使用一次握手源服务器返回“愿意接受请求”？
这只是我的猜测。
万斯
I found the apache xfire has add one head parameter in its post header:
POST /testservice/services/TestService1.1 HTTP/1.1
SOAPAction: "testAPI" Content-Type: text/xml; charset=UTF-8
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; XFire Client +http://xfire.codehaus.org)
Host: 192.168.10.111:9082
Expect: 100-continue
Will this Expect: 100-continue make the roundtrip call between the xfire client and its endpoint server a little bit waste because it will use one more handshake for the origin server to return the "willing to accept request"?
This just my guess.
Vance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我知道这是一个老问题，但由于我刚刚研究这个主题，这是我的答案。您实际上并不需要使用“Expect: 100-continue”，它确实会引入额外的往返。此标头的目的是向服务器表明您希望在发布数据之前验证您的请求。这也意味着如果它被设置，您将承诺在之前等待（在您自己的超时期限内 - 而不是无限期！）服务器响应（100或HTTP失败）发送您的表格或数据。虽然这看起来像是额外的费用，但它旨在通过允许服务器让您知道不发送数据（因为请求失败）来提高失败情况下的性能。
如果客户端未设置标头，则意味着您不会等待来自服务器的 100 代码，而应在请求正文中发送数据。这是相关标准： http://www.w3.org/Protocols/rfc2616/ rfc2616-sec8.html（跳至第 8.2.3 节）。
.NET 4 用户提示：可以使用静态属性“Expect100Continue”禁用此标头
。libcurl 用户提示：旧版本 7.15 中存在一个错误，禁用此标头不起作用；在较新版本中已修复（更多信息：http://curl.haxx.se /mail/lib-2006-08/0061.html）
I know this is old question but as I was just researching the subject, here is my answer. You don't really need to use "Expect: 100-continue" and it indeed does introduce extra roundtrip. The purpose of this header is to indicate to the server that you want your request to be validated before posting the data. This also means that if it is set, you are committed to waiting (within your own timeout period - not indefinitely!) for server response (either 100 or HTTP failure) before sending your form or data. Although it seems like extra expense, it is meant to improve performance in failure cases, by allowing the server to make you know not to send the data (since the request has failed).
If the header is not set by the client, this means you are not awaiting for 100 code from the server and should send your data in the request body. Here is relevant standard: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html (jump to section 8.2.3).
Hint for .NET 4 users: this header can be disabled using static property "Expect100Continue"
Hint for libcurl users: there was a bug in old version 7.15 when disabling this header wasn't working; fixed in newer versions (more here: http://curl.haxx.se/mail/lib-2006-08/0061.html)