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.