why was HTTP status code 102 removed from HTTP/1.1

Question

returning status 102 for a REST service that might take a long time to complete seems like it might sometimes be a good idea. A better idea is often to return a 202 accepted with a reference to URLs with the status of the request and which will have the final answer when its ready.

I note from https://evertpot.com/http/102-processing that status code 102 is not in the HTTP/1.1 spec (rfc2616). Why was it removed?

And given that it has been why are many people still using and recommending it? Is it because most services must support HTTP/1.0 for backwards compatibility and therefore it is likely to be implemented anyway?

Answer 1

According to RFC 1945 (HTTP/1.0), section 9.1:

9.1 Informational 1xx

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. HTTP/1.0 does not define any 1xx status codes and they are not a valid response to a HTTP/1.0 request. However, they may be useful for experimental applications which are outside the scope of this specification.

(Emphasis mine.)

So it's not that HTTP/1.1 removed 102; rather it added 100 and 101.

It even says so in RFC 2616:

10.1 Informational 1xx

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.

So where did 102 come from?

It's from RFC 2518 (WEBDAV):

10 Status Code Extensions to HTTP/1.1

The following status codes are added to those defined in HTTP/1.1 [RFC2068].

10.1 102 Processing

[...]