默认情况下，许多库在所有HTTP 1.1 POST和PUT请求中包含Expect: 100-continue。空“预期：”标题意味着什么？
我打算通过删除客户端上的100-继续机制来减少感知的延迟，因为我知道立即发送数据的费用少于等待100次继续的往返，即短期请求。
当然我还想要HTTP 1.1的所有其他强大功能，因此我只想杀掉Expect: 100-continue头。我有两个选择：
Expect:\r\n是否有过两者之间有什么区别？
任何软件可能会破坏一个或另一个？
应该休息，如果你删除Expect头，但我知道，微软的IIS已经有问题在过去
100 Continue
没有。例如，IIS5 always sends 100 continue responses。所以，我想知道它在图书馆中的至少一些用途可能是解决服务器中类似的破坏行为。
很多图书馆似乎设置了此标题，然后实际上并未正确处理100 Continue - 例如，他们开始立即发送请求主体而不用等待100 Continue，然后不处理服务器可能在发送请求主体之前发回任何HTTP错误代码这一事实（第一部分的确定，它是第二部分这是破碎的 - 见我的答案）。这使我相信有些作者刚刚从其他地方复制它，但没有完全理解the subtleties。
我看不到任何理由包含一个空白Expect标题 - 如果你不打算包括100-continue（或其他一些Expect子句），那么完全省略标题。包含它的唯一原因将是解决破碎的Web服务器，但我不知道有哪些行为以这种方式。
最后，如果你只是想减少往返延迟，在我看来，它不会实际上是与RFC不一致只是立即开始传输请求主体。你不应该无限期地等待发送请求主体（根据the RFC），所以你的行为符合规范 - 只是你的超时在发送之前是零。
您必须意识到，如果服务器已收到一些请求主体，那么服务器可以自由发送100 Continue响应，因此您必须处理发送100 Continue的服务器，这些服务器不发送任何内容并等待满请求和立即发送任何HTTP错误代码（可能是417，但更可能是通用4xx代码）的请求。这样，你的短请求不应该有任何开销（除了Expect标题），但你不必等待100 Continue。当然，要使这种方法起作用，您需要采取一种办法，让服务器返回错误代码（例如，使用poll()或select()的非阻塞IO）立即中断请求。
这样做可能有助于保持代码在小请求和大请求之间的一致性，同时减少延迟。不足之处在于，即使它没有明确违反任何要求，也可能不是RFC的作者所想的。另外，如果您还没有进行非阻塞IO或类似操作，它可能会使您的后续代码更加复杂。