使用 1xx 响应通过 HTTP 报告进度

Question

问题：通过 HTTP 提供进度信息

我正在编写一个应用程序，我想在其中提供长（呃）运行请求的进度信息。我希望客户端能够报告进度（例如完成百分比）并向用户发送消息。

HTTP 1xx 响应

我的目的是在最终 HTTP 响应之前使用 HTTP 1xx 响应来完成此操作。

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

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

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

为此目的使用“100 Continue”似乎（至少）违反了 RFC 2616 section 8.2.3 中描述的此状态代码的意图。

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

进度信息流

想法是在最终的“200 OK”响应之前使用一个或多个“102 Processing”响应将进度信息推送给客户端，因为每个响应（包括 1xx 响应）都有自己的 header 部分。

它可能看起来像这样：

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>

启用和禁用进度信息

服务器是否应该发送进度信息可以由请求中的自定义 header 字段控制 header（如上例所示）：

X-Progress: enable

如果此 header 不存在或设置为 disable，则不会从服务器向客户端发送进度信息和“102 Processing”响应。

自定义 header 的替代方法可能是

Expect: 102-Processing

但是根据 Expect 请求 header 中 RFC 2616 section 14.20 的描述，我不确定是否允许这样做。我担心大多数中介机构在收到“Expect: 102-Processing”请求时只会 return “417 Expectation Failed” header.

备选方案

在寻找替代方案时，我偶然发现了 2008 年的 http-progress draft，它提出了一种非常相似的方法，但我找不到关于这个想法的任何其他信息。

问题

这听起来像是一个可行的想法吗？或者有人有更好的想法，或者——甚至更好——针对我的问题的标准化解决方案？
使用“Expect: 102-Processing”是个好主意还是我应该坚持使用自定义请求header？

Answer 1

1) 您正在查看过时的规格。请查看 HTTP 的 RFC 7230...5（WebDAV 也已更新，但更新不再定义 102）。

2) Expect 不再允许使用“100-continue”以外的任何值（参见 http://greenbytes.de/tech/webdav/rfc7231.html#header.expect）

3) 您可能希望使用具有新首选项的 "Prefer" 而不是 Expect 或自定义 header 字段。参见 http://www.greenbytes.de/tech/webdav/rfc7240.html。

使用 1xx 响应通过 HTTP 报告进度

Reporting progress over HTTP using 1xx responses

http

http-headers

问题：通过 HTTP 提供进度信息

HTTP 1xx 响应

进度信息流

启用和禁用进度信息

备选方案

问题