Re: #535: No 1xx Status Codes

Julian,

On Jun 27, 2014, at 1:45 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> ...
>>> Why do we keep trailers, but not 1xx? I'd like to understand how we draw the line.
>> 
>> Since trailers are used to communicate header fields that depend on the message body, we need to keep those because otherwise the sender would need to know the entire contents of the message body before sending them in the request...
> 
> So are they used in practice? Not when communicating with browsers, right?

I don't know of any browsers that support trailers or HTTP Digest auth-int at the moment, no.

>> Status code 100 is really only useful in preventing a connection from being torn down due to an exception for a POST or PUT request, and HTTP/2 streams basically provide this functionality all the time.
>> 
>> Status code 101 is effectively replaced/supported by the HTTP/2 extension mechanism.
>> 
>> Status code 102 seems only useful as a way to let the client know that the server is still alive - perhaps PING frames could be used from the Client to verify that the server is still alive?  In any case, the whole "connection timeout" verbiage in RFC 2518 probably doesn't apply to HTTP/2 which expects clients to reuse existing connections rather than opening multiple connections.
>> 
>> Perhaps the thing to do here is just document what to do with 101 and 102 (the spec already talks about 100).
> 
> I'm really not interested a lot in 100/101/102 but in the *class* of error codes that's being taken away from us.

I'm not sure what we're losing: in the 17 years since HTTP/1.1 was published we've had a total of three 1xx status codes (and the most recent - 102 - was published as part of WEBDAV in 1999).  Acknowledging that the number of registered status codes is a poor measure of how useful the 1xx status codes are, what sort of use cases are you thinking of?

100 and 101 are clearly supported through specific HTTP/2 mechanisms.

102 *might* still have some use as an intermediate progress reporting state, even for HTTP/2, but the general keep-alive behavior should be unnecessary for HTTP/2.

What about just prohibiting 100 and 101 (with documentation on their replacements) and making some general statement about other 1xx status codes?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair