使用1xx响应通过HTTP报告进度 问题：通过HTTP提供进度信息

我正在编写一个应用程序，希望为长时间（er）运行的请求提供进度信息。我希望客户端能够向用户报告进度（例如完成百分比）和消息

HTTP 1xx响应 我的意图是在最终HTTP响应之前使用HTTP 1xx响应来实现这一点

根据“信息性1xx”响应，任何符合HTTP 1.1的客户端必须能够“在常规响应之前接受一个或多个1xx状态响应”

两个相关的候选响应代码是：

• 100继续
• 102处理（在中定义）

为此目的使用“100 Continue”（100 Continue）似乎（至少）违反了本状态代码的意图，如中所述

这就给我们留下了最初定义的“102处理”，但似乎非常适合这个目的

进展信息流 我们的想法是在最终“200 OK”响应之前使用一个或多个“102处理”响应将进度信息推送到客户端，因为每个响应（包括1xx响应）都有自己的标题部分

它可能是这样的：

Client                                    Server
--------->
GET /path/to/resource HTTP/1.1
X-Progress: enable

                                      <---------
       102 Processing
       X-Progress-Message: Fetching records (1/5)
       X-Progress-Fraction: 0.2 

                                      <---------
       102 Processing
       X-Progress-Message: Fetching records (2/5)
       X-Progress-Fraction: 0.40

       ...

       200 OK

       <response body>

如果此标题不存在或设置为禁用，则进度信息和“102处理”响应不会从服务器发送到客户端

自定义标头的替代方法可以是

Expect: 102-Processing

但是从

Expect

请求头中的描述来看，我不确定是否允许这样做。我担心大多数中介机构在显示“Expect:102 Processing”请求头时只会返回“417 Expectation Failed”

选择 在寻找替代方案时，我在2008年偶然发现了这一点，它提出了一种非常类似的方法，但我没有找到关于这个想法的任何其他东西

问题

这听起来像是一个可行的想法，还是有人对我的问题有更好的想法，甚至更好的标准化解决方案

使用“Expect:102 Processing”是个好主意，还是应该坚持使用自定义请求头

1） 你看到的是过时的规格。请查看RFCs 7230…5 for HTTP（WebDAV也已更新，但更新不再定义102）

2） 不再允许使用“100 continue”以外的任何值进行Expect（请参阅）

---

3） 您可能希望将“首选项”与新的首选项一起使用，而不是Expect或自定义标题字段。请参阅。

谢谢您的回答和良好的提示。警告1）我看到在RFC4918（WebDAV）中，“102处理”已被明确删除。这是否意味着使用它是错误的？我可以使用什么1xx响应代码来代替？Wrt 3）“首选”请求头听起来是个好主意。102仍在中注册，因此可以使用它。

Expect: 102-Processing