许多库Expect: 100-continue默认包含所有 HTTP 1.1 POST 和 PUT 请求。
我打算通过删除客户端上的 100-continue 机制来减少感知延迟，因为我知道立即发送数据的费用低于等待 100-continue 的往返，即短请求。
当然，我仍然想要 HTTP 1.1 的所有其他强大功能，因此我只想杀死Expect: 100-continue标头。我有两个选择：
Expect:\r\n两者之间有什么区别吗？
任何软件可能会因其中之一而中断？
如果您删除标头，什么都Expect不会中断，但我知道 Microsoft IIS 过去曾遇到过问题100 Continue。例如，IIS5 总是发送 100 个继续响应。所以，我想知道它在库中的至少一些用途是否可能是为了解决服务器中类似的破坏行为。
许多库似乎设置了这个标头，然后实际上并没有100 Continue正确处理 - 例如，它们开始立即发送请求正文而不等待 a100 Continue然后不处理服务器可能在它们完成之前发送回任何 HTTP 错误代码的事实发送请求正文（第一部分可以，第二部分已损坏 - 请参阅我的回答后面）。这使我相信有些作者只是从别处复制了它，而没有完全理解其中的微妙之处。
我看不出包含空白Expect标题的任何理由 - 如果您不打算包含100-continue（或其他一些Expect子句），则完全省略标题。包含它的唯一原因是解决损坏的网络服务器，但我不知道有任何行为以这种方式运行。
最后，如果您只是想减少往返延迟，在我看来，简单地立即开始传输请求正文实际上并不会与 RFC不一致。您不应该无限期地等待发送请求正文（根据RFC），因此您的行为符合规范 - 无论如何发送之前的超时时间为零。
您必须知道，如果服务器100 Continue已经收到一些请求正文，则服务器可以自由不发送响应，因此您必须处理发送100 Continue的服务器、不发送任何内容并等待完整请求的服务器以及立即发送的服务器任何 HTTP 错误代码（可能是 417，但更可能是通用 4xx 代码）。这样，您的短请求不应该有任何开销（除了Expect标题），但您不必等待100 Continue. poll()当然，要使这种方法发挥作用，您需要以一种允许您在服务器返回错误代码时立即中断请求的方式进行操作（例如，使用or的非阻塞 IO select()）。
以这种方式做事可能有助于使您的代码在小型和大型请求之间更加一致，同时减少延迟。缺点是它可能不是 RFC 作者的想法，即使它没有明确违反任何要求。此外，如果您还没有进行非阻塞 IO 或类似操作，它可能会使您以后的代码更加复杂。