Re: Getting to Consensus on 1xx Status Codes (#535)

Julian,

On Jul 17, 2014, at 9:22 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> ...
>>> Is this a proposal for an erratum for RFC 7231, or specific to HTTP/2?
>> 
>> Erratum for RFC 7231, since it should apply to all versions of HTTP.
> 
> OK, then please clarify in *how* this is an erratum. We currently say:
> 
> "If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response." -- <http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.6.2.1.p.3>
> 
> Isn't that sufficiently clear?

It specifies client behavior, but does not recommend a server behavior that improves interop, namely that a server should only respond with a 100 status if the client asks for it.  I know that wasn't the original explicit intent, but given 20 years of implementation experience it is reasonable to document "what works" vs. "what was specified".  It also allows HTTP/2 to support a specific semantic intent vs. a vague "1xx status code at any time" policy that has proven interoperability issues in HTTP/1.x.

>> ...
>>> Actually, it seems that it's silent on what the semantics of an 1xx in a HTTP/2 headers frame is. Valid? Non-final? If we keep 1xx out of HTTP/2, we should clearly state what it means. Right now we say
>>> 
>>> "An intermediary that gateways HTTP/2 to HTTP/1.1 MUST discard all other 1xx informational responses."
>>> 
>>> but what about the opposite case?
>> 
>> Right, thus my comment about it being impossible to gateway HTTP/1.1 Expect semantics to HTTP/2.
>> 
>> (If we can actually come up with a solution that doesn't require intermediate HEADER frames with a :status 100 header, fine, but so far I don't think we have it.)
> 
> So that proposal is sort of consistent with mine, except that you want to special-case 100. My preference would be to stay generic.

I prefer explicit semantics that promote interoperability and guaranteed functionality.  We already have three 1xx status codes with drastically different semantics, two that can be ignored safely (100, 102) and one that can't (101).  We also have almost 20 years of HTTP that has shown no real growth or experimentation with 1xx status codes, while 2xx, 3xx, 4xx, and 5xx have been widely extended and are supported with clear semantics even if the client doesn't understand a particular status code.

So yes I am OK with using an intermediate HEADERS frame being used to express the semantic for a 100 response in HTTP/2 which can be safely ignored by a client or intermediary, but I am NOT OK with leaving the door open for another 101-like response that cannot be safely ignored.  Thus, if instead we decide to use an EXPECT_WINDOW_UPDATE bit in the client's HEADERS frame and use the server's WINDOW_UPDATE on a stream as the replacement for a 100 response, that works for me too because it preserves the well-define semantics of using Expect: 100-continue in a client request to elicit a "go ahead" response from the server if the request can continue to be submitted.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair