摘要

  • Expect: 100-continue 表示客户端准备暂缓正文，让服务器先按方法、目标与请求头给出可提前确定的最终拒绝。
  • 100 只鼓励继续传输；源站仍欠一个最终状态，而中间代理有时也能自行发出这份临时许可。
  • 客户端可以超时后不等 100 直接发送。这条单边出口防止旧中间设备吞掉 1xx 后造成互等。

可以先判断的部分先到了

HTTP 请求先送请求行和头部，再送可选正文。服务器因此可能在文件到来之前就识别出 401、405 或其他最终错误。立即发送全部内容会浪费链路；毫无约定地等待，又会让客户端等许可、服务器等正文。

RFC 2068 在 1997 年已经定义 100 这一信息状态，并处理 HTTP/1.0 中间节点无法可靠转发它的问题。早期规则需要版本记忆、等待与重试，说明“先问再发”从一开始就受部署不一致约束。

Expect 把等待意图写进请求

RFC 2616 加入 Expect 与 100-continue。服务器终于能区分“客户端正在扣住正文”和“正文紧跟头部已经在路上”。

打算等待的客户端必须显式声明；没有正文时不得声明。服务器若已经收到部分或全部正文，也可省略失去意义的 100。

源站收到完整 HTTP/1.1 头部、正文标记和期待后，必须立刻二选一：若头部足以决定结果，就返回最终状态；否则立即发 100，不得先等正文。许可不能反过来依赖被许可发送的对象。

Continue 没有承诺成功

1xx 是临时信息，不结束请求。服务器发过 100 后，仍需接收、处理正文并给出最终状态，除非连接提前断开。

它只说明目前所见不足以阻止发送，不证明身份通过、内容有效、数据持久化、方法执行或结果成功。正文解析、配额、存储和内容相关授权仍可能失败。

因此它不是事务预提交，也不是两阶段提交的准备票。它管理的是传输开销，不是操作语义。

代理能放行，却不能替源站接受

代理可以返回自己能确定的最终状态，也可以把头部继续转发。若它知道下一跳较旧，有时会自行生成 100，使客户端不要久等。

这份回答只证明当前链路愿意搬运正文，不证明源站已经看到或接受。日志若只记“收到 100”而不记发送跳点，就把局部通行许可伪装成端到端结论。

417 表示链路无法满足期待。客户端可去掉期待再试，但取消优化不自动使有副作用的方法适合重放；仍需查清哪些字节或效果到达源站。

沉默不能获得无限否决权

RFC 7231 与 RFC 9110 保留客户端的单边前进权：没有规定必须等待的固定时长，客户端即使没收到 100 也可开始发送，而且不应无限等待。

旧节点可能吞掉临时回应，源站也可能已经在读。有限等待用少量潜在浪费换取进展，避免一次节省带宽的协商变成静默控制权。

规范没有给出适用于所有路径的正文大小或延迟阈值。正文较小时，多一次决策往返可能得不偿失。协议划分责任，不替每个运营者完成性能判断。

最终拒绝之后仍有报文边界

客户端仍在发送时，最终状态可能已经返回。服务器要么关闭连接，要么继续读完并丢弃剩余正文，才能让后续消息保持正确边界。

应用裁决与连接处置是两条事实。若双方对残留字节含义不一致，复用连接可能把旧正文误当成下一条请求。

来源与边界

封闭来源为 RFC 2068、RFC 2616、RFC 7231 与 RFC 9110。它们确立历史与语义，不提供当前部署、默认超时、中间设备合规率或带宽收益。