Reporting progress over HTTP using 1xx responses

Question

Problem: Provide progress info over HTTP

I am writing an application where I would like to provide progress information for long(er) running requests. I would like the client to be able to report progress (e.g. percent completed) and a message to the user.

HTTP 1xx responses

My intention is to accomplish this using HTTP 1xx responses before the final HTTP response.

According to RFC2616 section 10.1 on “Informational 1xx” responses any compliant HTTP 1.1 client must be able to “accept one or more 1xx status responses prior to a regular response”.

The two relevant candidate response codes are:

• 100 Continue
• 102 Processing (defined in RFC 2518)

Using “100 Continue” for this purpose seems to be (at least) a violation of the intention of this status code as it is described in RFC 2616 section 8.2.3.

This leaves us with “102 Processing” which was originally defined for WebDAV but seems perfect for this purpose.

Flow of progress information

The idea is to use one or more “102 Processing” responses prior to the final “200 OK” response to push the progress information to the client as each response – including 1xx responses – have their own header section.

It could look like this:

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>

Enabling and disabling progress information

Whether or not the server should send the progress information could be controlled by a custom header field in the request header (like in the example above):

X-Progress: enable

If this header is not present or is set to disable, progress information and “102 Processing” responses are not sent from the server to the client.

An alternative to a custom header could be

Expect: 102-Processing

but from the description in RFC 2616 section 14.20 on the Expect request header, I am not sure whether that is allowed or not. I would fear that most intermediaries would simply return “417 Expectation Failed” when presented with the “Expect: 102-Processing” request header.

Alternatives

When searching for alternative I stumbled upon this http-progress draft from 2008 that proposes a very similar approach but I haven't been able to find anything else about this idea.

Questions

1. Does this sound like a viable idea or does anybody have a better idea or – even better – a standardised solution to my problem?
2. Is the use of “Expect: 102-Processing” a good idea or should I stick with a custom request header?

Answer 1

1) You're looking at outdated specifications. Please have a look at RFCs 7230...5 for HTTP (WebDAV has been updated as well, but the update doesn't define 102 anymore).

2) Expect with any value other than "100-continue" isn't allowed anymore (see http://greenbytes.de/tech/webdav/rfc7231.html#header.expect)

3) Instead of Expect or a custom header field you might want to use "Prefer" with a new preference. See http://www.greenbytes.de/tech/webdav/rfc7240.html.