设置Expect:100-continue请求头时Fiddler引入延迟的原因

这个固定延迟是Fiddler代理的默认兼容逻辑导致的，和网络传输、系统性能开销无关：

• 先明确HTTP协议中Expect: 100-continue的设计规则：客户端发送大体积请求体时，可以先只发送请求头，等待服务端返回100 Continue响应后再发送实际请求体，避免发送了大体积请求才被服务端拒绝（比如鉴权失败、请求体超过大小限制），白白浪费带宽资源。
• Fiddler作为中间人代理，默认不会在收到客户端的Expect: 100-continue请求头后立刻转发给目标服务端，而是会启动一个1秒的等待计时器：
  • 这个等待窗口是为了兼容早期不规范的HTTP客户端实现：部分老版本客户端可能在发完请求头后直接取消请求，不会发送后续请求体。如果Fiddler不做等待直接把请求头转发给服务端，会让服务端产生大量等待请求体的无效空连接，占用服务端连接资源。
  • 计时器触发两个处理分支：如果1秒内客户端主动发送了请求体，Fiddler就会把完整请求正常转发给服务端；如果1秒内客户端既没取消请求也没发送请求体，Fiddler会先主动给客户端返回100 Continue响应，再把请求转发给服务端。
• 目前绝大多数主流HTTP客户端（浏览器、各类开发SDK等）的实现逻辑，都是发送Expect: 100-continue头之后不会等满1秒就会准备发送请求体，Fiddler这个固定的1秒等待窗口就成了无意义的阻塞，直接表现为所有带该请求头的请求都会额外增加约1秒的延迟。

已知的配置修复方法，本质就是关闭这个默认的1秒等待逻辑，让Fiddler收到对应请求头后立刻转发给目标服务端，由服务端自主决定是否返回100 Continue，即可完全消除这部分额外开销。

内容的提问来源于stack exchange，提问作者arinto