Re: #535: No 1xx Status Codes

Julian,

On Jun 27, 2014, at 5:20 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2014-06-27 09:56, Mark Nottingham wrote:
>> <https://github.com/http2/http2-spec/issues/535>
>> 
>> This seems like a re-opening of <https://github.com/http2/http2-spec/issues/264>. We discussed it a fair amount in the Seattle interim, and there was pretty strong support in the room for getting rid of 1xx status, especially since they're poorly supported in implementations, almost non-existant in APIs, and often don't survive hop-to-hop.
>> 
>> Julian, anything to add? I'm inclined to close this as a duplicate unless there's significant new information...
> 
> I still fail to see a compelling reason to remove them.
> 
> 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...

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).

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair