为什么添加expect:100-continue请求头后SocketTimeoutException消失

Expect: 100-continue能解决本次SocketTimeoutException的核心逻辑和两端服务的交互机制有关，具体如下：

未加请求头时的超时触发逻辑 #

• 没有带Expect: 100-continue的情况下，Apache HttpClient会直接把请求头、1277字节的JSON请求体一次性全部发给对端的ASP.NET服务
• IIS托管的ASP.NET服务默认有固定的前置校验流程：收到完整请求头后，先跑请求头合规校验、身份鉴权、内容长度校验等逻辑，所有校验通过后才会开始读取请求体、处理业务，最后返回响应
• 本次报错是读超时，说明你的HttpClient设置的Socket读取超时阈值，比「服务端前置校验+读取请求体+业务处理」的总时长短，客户端等不到响应就抛出了异常。还有一种常见的场景是：部分ASP.NET服务默认会对不带Expect: 100-continue的较大体积POST请求做几秒的延迟处理，用来防控恶意大流量，也会直接触发短超时设置的读超时错误。

加了Expect: 100-continue后的流程变化 #

这个请求头的核心作用是把请求拆成两个交互阶段，把服务端前置校验的耗时从读超时的统计周期里剥离出来：

1. 客户端先只发带Expect: 100-continue的请求头，不发送请求体
2. 服务端完成所有前置校验后，会立刻返回100 Continue响应，通知客户端可以发送请求体
3. 客户端拿到确认响应后，再发送JSON请求体，之后等待服务端返回业务处理结果
4. Apache HttpClient对第一阶段等待100响应的超时是单独统计的，不会占用后续业务请求的读超时配额，自然就不会触发原来的超时错误。

• 部分旧版本的反向代理、Web服务不支持Expect: 100-continue头，会返回417 Expectation Failed错误，后续切换对端服务时要注意适配
• 如果后续业务逻辑复杂度上升，处理时长超过你设置的读超时阈值，仍然可能触发超时，建议根据业务实际情况调整合理的超时配置

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