HTTP 1xx 中间响应与 102 Processing：面试如何判断协议边界？

题干与适用场景

面试官可能会问：“HTTP 1xx 中间响应和 102 Processing 分别表示什么？如果一个长请求需要进度反馈，你会怎么设计？”

这道题考察你能否区分请求仍未结束的协议信号、最终响应和异步任务状态资源。RFC 9110 规定一次请求可以先收到零个或多个 1xx 中间响应，最后仍要收到一个非 1xx 的最终响应；它没有把 102 定义成通用的进度百分比协议。102 的历史定义来自 WebDAV RFC 2518，后来被 RFC 4918 从 WebDAV 中移除。回答时应先澄清协议版本、客户端和代理能力，再决定是否采用它。

面试官考察点

• 是否知道 1xx 是中间响应，不能代表请求已经完成。
• 是否能区分 100 Continue、101 Switching Protocols 与 102 Processing 的语义。
• 是否识别 102 的 WebDAV 历史边界，不把它当成跨客户端可依赖的通用进度 API。
• 是否能为长任务选择 202 加状态端点、SSE 或 WebSocket 等更稳定的产品协议。
• 是否考虑代理转发、超时、重试、取消、幂等和最终结果读取。

回答前需要澄清的问题

• 请求是同步保持连接，还是可以改成后台任务？
• 客户端、反向代理和网关是否会转发并暴露 1xx？
• 业务需要的是“仍在处理”的保活信号，还是可观察的阶段和百分比？
• 任务是否有副作用，客户端重试是否可能重复执行？
• 完成结果是否有独立资源、下载地址、过期时间和访问控制？

30 秒回答框架

可以这样回答：

1xx 是最终响应之前的中间响应；客户端最终仍要等待一个非 1xx 的结果。102 Processing 源于 WebDAV 的长处理场景，不能自然承载通用进度模型，也不能假设所有代理都会按预期传递。若任务可异步化，我会返回 202 和带权限的状态资源，状态资源提供稳定状态、错误、取消和结果链接；若必须保持连接，再根据客户端能力考虑 SSE 或其他明确的事件协议，并验证代理行为。

分步骤深入解答

先定义响应生命周期

把一次请求拆成中间阶段与最终阶段：

HTTP/1.1 102 Processing

HTTP/1.1 200 OK
Content-Type: application/json

{"result":"done"}

102 不结束请求，也不携带“任务完成”的承诺。RFC 9110 的关键约束是最终仍要有一个非 1xx 响应；中间响应丢失时，客户端也不能据此推断业务失败。

再划清 102 的适用边界

RFC 2518 曾把 102 用作 WebDAV 长操作的处理中提示，目的是避免客户端误判连接失活。它不是带 percentComplete、阶段枚举和错误契约的通用工作流资源。RFC 4918 移除了该 WebDAV 状态码定义，因此设计新 API 时必须说明目标实现和兼容性，不能只凭状态码数字作跨栈承诺。

为产品需求选择协议

若客户端可以轮询，优先把动作与状态分离：提交返回 202 和 Location，状态资源返回 Pending、Running、Succeeded、Failed、Canceled 等稳定状态。若需要实时展示阶段，可在状态资源之上增加 SSE；若需要双向控制，再评估 WebSocket。每种方案都要给出断线恢复、重试退避、取消语义和授权检查。

处理重复提交与最终一致性

为创建任务提供幂等键，服务端保存请求指纹和任务 ID；重试同一键时返回同一任务，而不是再次排队。状态资源的读取应可重复，结果下载地址应短期有效并绑定租户。失败状态需要结构化错误和可重试边界，不能把 102 或连接断开当作业务结论。

高质量示范回答

我先确认需求是保活提示还是可观察的任务进度。如果只是同步请求可能超过网关超时，我不会直接把 102 当成通用进度接口：1xx 是最终响应前的中间响应，102 的语义还有 WebDAV 历史，代理和客户端支持也不一致。我的默认设计是提交接口校验参数后返回 202、任务 ID 和状态 URL；状态资源公开有限的阶段、更新时间、结构化错误、取消入口和结果 URL，并用 Retry-After 给出轮询建议。提交带幂等键，重试不会重复创建任务。需要实时界面时再提供 SSE，并让客户端用最后事件 ID 或状态资源恢复。若安全、合规或数据暴露风险出现，我会保留最终响应之外的审计记录并走正式升级路径。这样协议信号、任务状态和结果资源各自有清晰边界。

常见错误

• 把 102 说成“进度百分比响应”，却没有标准字段或客户端契约。
• 认为收到任何 1xx 就可以关闭连接或认为请求成功。
• 忽略 RFC 4918 移除 102 的历史，直接声称所有 WebDAV 客户端都支持。
• 只讨论服务器发送响应，不验证 CDN、代理、网关和浏览器的实际行为。
• 返回 202 却没有状态资源、幂等策略、失败状态或结果访问控制。
• 把断线、超时和重试当作任务失败，导致重复副作用。

追问及应对

1. 102 和 202 的核心区别是什么？

102 是同一请求的中间响应，最终响应仍在后面；202 是最终响应，表示请求已被接受处理，但结果可能尚未完成。长任务若需要客户端独立观察和恢复，202 加状态资源通常更清晰。

2. 代理不转发 1xx 时怎么办？

把 1xx 视为可选优化，不能作为业务正确性的唯一依据。通过状态端点、SSE 或受控客户端链路提供可恢复的状态，并在真实代理链路上做兼容性测试。

3. 什么时候仍会使用 102？

只有在端到端实现明确支持、需求确实是同一长请求的处理中提示、且团队接受兼容性边界时才考虑。应记录客户端、代理和超时验证结果，并准备无 102 时仍正确工作的降级路径。