102 Processing
102 Processing is a pretty rare status code. It’s not in the official
newer HTTP specifications, and its only appearance is in an obsolete
version of the WebDAV specification. It was left out of the current
WebDAV specification, and more recent HTTP specifications.
When the server sends back the 102 Processing status code, it informs a
client that the full request has been received, the server is working on it,
and that a real status code will be sent back later.
In that sense it’s somewhat similar to 100 Continue. The difference is
that 100 Continue might be returned immediately, and 102 Processing only
after the full request has been received. The suggestion from the specification
is to do this if handing the request is going to take longer than 20 seconds.
One way to look at it, is that it’s a mechanism for the server to tell the client that ‘its not dead yet’, and it might help avoid timeouts.
Example
[client sends request headers]
HTTP/1.1 100 Continue
[client sends request body]
HTTP/1.1 102 Processing
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
Usage
Although 102 has been left out more recent revisions of HTTP specifications,
it is out there in the wild.
Specifically, Node.js has built-in support for it via the
writeProcessing() function. I also noticed that Cloudflare takes
advantage of this. Cloudflare is a Proxy/CDN, and to avoid Cloudflare timing
out and assuming that a origin server is dead, a 102 Processing header should
be emitted at least every 100 seconds.
Good HTTP clients should ignore 1xx headers they don’t understand, so using
102 processing should be safe. Although unlike 100 Continue, a client
doesn’t explicitly opt-in to 102 Processing behavior.
So should you use it? I’m on the fence and want to say ‘Maybe’. Definitely make sure that the clients you want to support don’t trip up.