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

Julian,

On Jul 17, 2014, at 8:02 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2014-07-17 13:32, Michael Sweet wrote:
>> ...
>> - We should only deprecate *new* 1xx status codes.
> 
> Why would we actually want to deprecate them? Do we have a standardized replacement?

First, because in the almost 20 years since RFC 1945 (HTTP/1.0) was published, we have only ever come up with three 1xx status codes, one of which has already been deprecated (102) due to lack of use/implementation, and another (101) that has been effectively been replaced by ALPN for HTTPS.  That tells me that 1xx status codes have limited usefulness.

Second, there are well-known interoperability limitations to 1xx status codes - clients cannot depend on end-to-end support through intermediaries, which is why any good HTTP client that uses Expect: 100-continue implements a short go-ahead timeout in case a 100 response is not received by/forwarded to the client, and why HTTP Upgrade has been rejected by many to support cleartext HTTP/2.0.

>> - We should formally deprecate 102 - 4918's mention of it being removed in an appendix isn't particularly visible. We can reference RFC 4918 for the deprecation but we should actually remove 102 from the registry (or mark it as deprecated).
> 
> What's the benefit of removing it from the registry?

Just so that people don't use it.  Even updating the registry to say "(deprecated in RFC 4918)" in the description will be useful since the only mention of 102 in RFC 4918 is buried in the appendix and RFC 2518 is the only thing you see in the registry.

>> - For 100 status codes, we can clarify that they must only be sent by a HTTP server if the client includes the Expect: 100-continue header in its request.  Thus, the client (application) is stating its ability to handle non-final responses by requesting the non-final response behavior.
> 
> 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.

However, if we *do* publish a separate document about 1xx status codes then it might as well go there until/unless 7231 is updated.  (Best practice/implementor's guide documents are a good thing IMHO)

>> - We can also provide interoperability recommendations for 100-continue: clients SHOULD NOT wait indefinitely for a 100 response before sending the request message body.
> 
> RFC 7231 already says:
> 
> "A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the message body even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the message body." -- <http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.1.1.p.7>

OK, good - missed that (wish we still had a single document to find this stuff; I'll get used to it in time I'm sure...)

>> - I believe that the HTTP/2 document addresses status code 101 sufficiently for HTTP/2.  Perhaps the B document can reference HTTP/2 so that it is clear that 101 is only for 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.)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair