空"Expect:"标题是什么意思？

Question

Expect: 100-continue默认情况下,许多库包含所有HTTP 1.1 POST和PUT请求.

我打算通过在客户端删除100-continue机制来减少感知延迟,我知道立即发送数据的费用少于等待100-continue的往返,即短请求.

当然我仍然想要HTTP 1.1的所有其他强大功能,因此我只想杀死Expect: 100-continue标题.我有两个选择:

• 完全删除expect头,或者
• 发送空的expect头, Expect:\r\n

这两者之间有什么区别吗？

任何软件可能会破坏其中一个？

Answer 1

如果删除标题,什么都不应该破坏Expect,但我知道Microsoft IIS过去曾遇到过问题100 Continue.例如,IIS5始终发送100个继续响应.所以,我想知道它在库中的至少一些用途是否可以解决服务器中类似的破坏行为.

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

我看不出任何理由包含空白Expect标题 - 如果您不打算包含100-continue(或其他一些Expect子句),则完全省略标题.包含它的唯一原因是解决损坏的Web服务器,但我不知道有任何行为方式.

最后,如果您只是想减少往返延迟,我认为它实际上与RFC 不一致,只是立即开始传输请求体.你不应该无限期地等待发送请求体(根据RFC),所以你的行为符合规范 - 只是你的超时才会发送,无论如何是零.

你必须知道,服务器是自由地不发送100 Continue,如果他们已经收到了一些请求主体的反应,所以你必须处理其发送服务器100 Continue,那些没有任何响应,并等待完整的请求和那些立即发送任何HTTP错误代码(可能是417,但更可能是通用的4xx代码).通过这种方式,您的短请求不应该有任何开销(除了Expect标题),但您不必等待100 Continue.当然,对于这种工作方法,您需要以一种方式执行操作,以便在服务器返回错误代码时立即中断请求(例如,带poll()或的非阻塞IO select()).

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