ajax - 空的 "Expect:" header 有什么意义吗？

Question

默认情况下，许多库在所有 HTTP 1.1 POST 和 PUT 请求上都包含 Expect: 100-continue。

我打算通过删除客户端上那些请求的 100-Continue 机制来减少感知延迟，对于这些请求，我知道立即发送数据的费用低于等待 100-Continue 的往返(即短请求)。

当然，我仍然想要 HTTP 1.1 的所有其他强大功能，因此我只想删除 Expect: 100-continue header 。我有两个选择:

• 完全删除期望 header ，或者
• 发送空的期望 header ，期望:\r\n

两者有什么区别吗？

有任何软件可能会损坏其中之一吗？

Answer 1

如果删除 Expect header ，应该不会破坏任何内容，但我知道 Microsoft IIS 过去曾遇到过 100 Continue 问题。例如，IIS5 always sends 100 continue responses 。因此，我想知道它在库中的至少一些用途是否可以解决服务器中类似的破坏行为。

许多库似乎设置了此 header ，但实际上并未正确处理 100 Continue - 例如他们立即开始发送请求正文，而不等待 100 Continue，然后不处理服务器可能在完成发送请求正文之前发回任何 HTTP 错误代码的事实(第一部分没问题，第二部分坏了 - 请参阅我的答案后面的部分)。这让我相信一些作者只是从其他地方复制了它而没有完全理解the subtleties .

如果您不打算包含 100-continue (或其他一些 Expect 子句)，然后完全省略 header 。包含它的唯一原因是解决损坏的网络服务器，但我不知道有任何这样的行为。

最后，如果您只是想减少往返延迟，在我看来，立即开始传输请求正文实际上与 RFC 并不不一致。您不应该无限期地等待发送请求正文(根据 the RFC )，因此您的行为符合规范 - 这只是发送之前的超时为零。

您必须注意，如果服务器已经收到部分请求正文，则可以不发送 100 Continue 响应，因此您必须处理发送 100 的服务器继续，那些不发送任何内容并等待完整请求的人，以及那些立即发送任何 HTTP 错误代码(可能是 417，但更可能是通用 4xx 代码)的人。这样，您的短请求不应该有任何开销(除了 Expect header )，但您不必等待 100 Continue。当然，要使这种方法发挥作用，您需要以某种方式进行操作，以便在服务器返回错误代码时立即中断请求(例如使用 poll() 进行非阻塞 IO) > 或 select())。

以这种方式执行操作可能有助于使代码在小型请求和大型请求之间更加一致，同时减少延迟。缺点是这可能不是 RFC 作者的初衷，即使它没有明确违反任何要求。此外，如果您还没有进行非阻塞 IO 或类似操作，它可能会使您以后的代码更加复杂。