我正在编写一个应用程序,我想为长(呃)运行请求提供进度信息。我希望客户能够向用户报告进度(例如完成百分比)和消息。
我的目的是在最终的HTTP响应之前使用HTTP 1xx响应完成此操作。
根据{Information 3xx}响应的RFC2616 section 10.1,任何兼容的HTTP 1.1客户端必须能够“在常规响应之前接受一个或多个1xx状态响应”。
两个相关的候选答案代码是:
为此目的使用“100 Continue”似乎(至少)违反了此状态代码的意图,如RFC 2616 section 8.2.3中所述。
这给我们留下了“102 Processing”,它最初是为WebDAV定义的,但似乎很适合这个目的。
这个想法是在最终的“200 OK”响应之前使用一个或多个“102 Processing”响应将进度信息推送到客户端,因为每个响应 - 包括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>
服务器是否应该发送进度信息可以由请求标头中的自定义标头字段控制(如上例所示):
X-Progress: enable
如果此标头不存在或设置为disable
,则不会从服务器向客户端发送进度信息和“102处理”响应。
自定义标题的替代方法可以是
Expect: 102-Processing
但是根据Expect
请求标题中的RFC 2616 section 14.20中的说明,我不确定是否允许这样做。我担心大多数中介会在出现“Expect:102-Processing”请求标题时返回“417 Expectation Failed”。
在寻找替代方案时,我偶然发现了2008年的这个http-progress draft提出了一个非常类似的方法,但我还没有找到关于这个想法的任何其他内容。
答案 0 :(得分:3)
1)您正在查看过时的规格。请查看HTTP的RFC 7230 ... 5(WebDAV也已更新,但更新不再定义102)。
2)预期除了&#34; 100-continue&#34;之外的任何其他值。是不允许的(见http://greenbytes.de/tech/webdav/rfc7231.html#header.expect)
3)您可能希望使用&#34;首选&#34;而不是Expect或自定义标题字段。有了新的偏好。请参阅http://www.greenbytes.de/tech/webdav/rfc7240.html。