HTTP 上传停顿与 Expect: 100-continue
识别 Expect: 100-continue 交互，并将其短暂的决策点与传输过程中停滞的上传区分开来。
连接建立。请求头发送出去。文件看起来没有移动。一种解释是客户端在发送正文之前，正在等待 Expect: 100-continue 的响应。
该机制让接收方在可能很大的上传被发送之前，仅凭请求头就拒绝请求。通常的成功顺序是：
request headers → 100 Continue → request body → final response100 是信息性状态：它允许客户端继续，但不表示文件已保存或应用操作已成功。返回 HTTP 417 的 Git push 就是一个具体的期望落空案例。
确定客户端收到的是哪种响应
| 观察 | 需要排查的含义 |
|---|---|
| 100 Continue | 客户端可以继续发送正文 |
| 正文之前的最终拒绝 | 操作在请求头阶段就被拒绝 |
| 没有预期的中间响应 | 客户端的等待策略与该路径上的处理方式 |
curl 提供专门的 expect-continue 等待设置。如果该 libcurl 等待在未收到预期响应的情况下到期，它仍会发送正文；到期本身并不自动意味着整个传输失败。该设置与允许整个传输完成的时间是分开的。增大后者可能让同样的初始停顿依然无法解释。
还要确定 Expect 是由哪一段 HTTP 会话承载的。使用普通 CONNECT 连接 HTTPS 目标时，网站的上传交互位于 TLS 内部；正向代理并不会简单地检查其内部的期望头。拦截或明文转发路径则不同。
移除该期望可以是有意的兼容性选择，但这意味着客户端可能在得知早期拒绝之前就开始发送很大的正文。请将该行为与实际需求进行比较。不要把针对旧代理的历史性变通方案描述成从每次上传中都删除该头的通用指令。