默认情况下，许多库在所有HTTP 1.1 POST和PUT请求中都包含Expect: 100-continue。
我打算通过在客户端删除100-continue机制来减少感知延迟，我知道立即发送数据的费用少于等待100-continue的往返，即短请求。 / p>
当然我仍然想要HTTP 1.1的所有其他强大功能，因此我只想杀死Expect: 100-continue标头。我有两个选择：
Expect:\r\n 两者之间有什么不同吗？
任何软件可能会破坏其中一个？
答案 0 :(得分：9)
如果删除Expect标题， 应该，但我知道Microsoft IIS过去曾遇到100 Continue问题。例如，IIS5 always sends 100 continue responses。所以，我想知道它在库中的至少一些用途是否可以解决服务器中类似的破坏行为。
许多库似乎设置了此标头，然后没有正确处理100 Continue - 例如他们开始立即发送请求主体而不等待100 Continue，然后不处理服务器在完成发送请求主体之前发回任何HTTP错误代码的事实（第一部分没问题，这是第二部分被打破 - 见后面的答案）。这让我相信一些作者刚从其他地方复制过而没有完全理解the subtleties。
我看不出有任何理由要包含空格Expect标头 - 如果您不打算包含100-continue（或其他Expect条款），则完全省略标题。包含它的唯一原因是解决破碎的网络服务器，但我不知道有任何行为方式。
最后，如果您只是希望减少往返延迟，我认为它实际上与RFC 不一致只是立即开始传输请求体。你不应该无限期地等待发送请求正文（按照the RFC），所以你的行为符合规范 - 只是你的超时才发送，无论如何是零。
您必须知道，如果服务器已经收到了部分请求主体，则可以自由发送100 Continue响应，因此您必须处理发送100 Continue的服务器，什么都不发送，等待完整的请求和那些立即发送任何HTTP错误代码（可能是417，但更可能是通用的4xx代码）。这样，您的短请求不应该有任何开销（除Expect标题之外），但您不必等待100 Continue。当然，对于这种工作方法，您需要以一种方式执行操作，以便在服务器返回错误代码时立即中断请求（例如，使用poll()或{{1的非阻塞IO }}）。
以这种方式执行操作可能有助于在小型和大型请求之间保持代码更加一致，同时减少延迟。缺点是它可能不是RFC作者的想法，即使它没有明确违反任何要求。此外，如果您尚未执行非阻塞IO或类似操作，它可能会使您的后续代码更复杂。