为可能需要很长时间才能完成的 REST 服务返回状态 102 似乎有时是个好主意。 一个更好的想法通常是返回一个 202 接受，并引用带有请求状态的 URL，并且当它准备好时会有最终答案。
我从https://evertpot.com/http/102-processing 注意到状态代码 102 不在 HTTP/1.1 规范中 (rfc2616)。 为什么要删除它？
既然如此，为什么还有很多人仍在使用和推荐它？是不是因为大多数服务都必须支持 HTTP/1.0 才能向后兼容，所以无论如何它都有可能实现？
【问题讨论】：
标签： http
它没有被“删除”。它是已注册 HTTP 状态代码的一部分，请参阅 https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml。请注意，没有一个 RFC 定义“所有”状态代码。另请注意，一般情况下，状态代码适用于所有版本的 HTTP。
【讨论】：
正如 @melpomene 所述，HTTP 状态代码 102 从未成为官方 HTTP 规范的一部分。它属于WebDAV工作组制作的“HTTP Extensions”文档。
它首次出现在 1999 年 2 月发布的“HTTP Extensions for Web Distributed Authoring and Versioning – WebDAV”RFC 2518 中。
该文档已被 2007 年 6 月发布的“HTTP Extensions for Distributed Authoring – WebDAV”RFC 4918 取代。已删除：
注意：HTTP 状态码 102（处理中）已在本规范中删除；其 IANA 注册应继续参考 RFC 2518。
由于缺乏实现，HTTP 状态代码 102（[RFC2518]，第 10.1 节）和 Status-URI 响应标头（第 9.7 节）的定义已被删除。
【讨论】：
根据RFC 1945（HTTP/1.0），section 9.1：
9.1 信息 1xx
此类状态码表示临时响应， 仅由状态行和可选标题组成，并且是 以空行结束。 HTTP/1.0 没有定义任何 1xx 状态 代码，它们不是对 HTTP/1.0 请求的有效响应。 但是，它们可能对实验性应用有用 超出了本规范的范围。
（强调我的。）
所以并不是 HTTP/1.1 去掉了 102；而是添加了 100 和 101。
10.1 信息 1xx
此类状态码表示临时响应， 仅由状态行和可选标题组成，并且是 以空行结束。没有必需的标题 状态码类。 由于 HTTP/1.0 没有定义任何 1xx 状态 代码，服务器不得向 HTTP/1.0 客户端发送 1xx 响应 除非在实验条件下。
那么 102 是从哪里来的呢？
来自RFC 2518 (WEBDAV)：
HTTP/1.1 的 10 个状态码扩展
以下状态代码添加到 HTTP/1.1 中定义的状态代码 [RFC2068]。
10.1 102 处理
[...]
【讨论】：