Expect 是什么
Expect 请求头让客户端在发出大请求体之前先问一句：服务器是否愿意接收。规范里目前只定义了一个标准取值 100-continue，含义是「请先用 100 状态码告诉我可以开始发正文」。这样客户端就不必在服务器注定会拒绝（例如权限不足、体积超限）时白白上传几十兆数据。服务端若不认识该期望，应回 417 拒绝整个请求。
基本信息
| 名称 | Expect |
|---|---|
| 唯一标准取值 | 100-continue |
| 规范 | RFC 9110 §10.1.1 |
| 配套状态码 | 100 Continue 允许发送，417 表示无法满足期望 |
| 适用版本 | HTTP/1.1 机制，HTTP/2 未定义该字段 |
| 常见触发 | 客户端对较大的请求体默认携带该头 |
交互时序
| 步骤 | 客户端 | 服务端 |
|---|---|---|
| 1 | 发送请求头并声明期望 | 收到后判断是否接受 |
| 2 | 等待响应 | 回 100 Continue 或直接回最终响应 |
| 3 | 收到 100 后发送正文 | 接收正文并处理 |
| 4 | 收到最终响应 | 返回 200、413 等结果 |
| 替代路径 | 超时后自行发送正文 | 部分实现直接忽略该头 |
客户端行为与绕过
客户端行为与绕过
# curl 对较大的请求体默认携带 Expect: 100-continue
# 老网关回 417 或一直不回应答时可禁用该头：
curl -si --expect100-timeout 1 -H 'Expect:' -X POST -d @big.bin https://upload.example.com/
# 想观察完整交互时打开详细模式
curl -sv -H 'Expect: 100-continue' -X POST -d @big.bin https://upload.example.com/ 2>&1 | head -20典型使用场景
- 大文件上传：先确认服务器接受再传，避免无效流量
- 上传接口排障：区分是权限或体积被拒，还是传输中途失败
- 老网关兼容性验证：确认中间设备是否支持该机制，必要时在客户端禁用
- 接口自动化：脚本里控制超时时间，避免因等待应答而长时间挂起
- 排查上传慢：确认是否存在等待 Continue 的额外往返
该机制只在 HTTP/1.1 中定义，HTTP/2 与 HTTP/3 没有这个字段，流控制与帧机制取代了它的作用。因此同一客户端在降级到 HTTP/1.1 时才可能出现相关行为差异，排查此类问题时先确认实际使用的协议版本。