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

On 2014-07-17 15:03, Michael Sweet wrote:
> 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.

All intermediaries need to do is implement what the HTTP 1.1 RFCs tell 
them with respect to handling of non-final messages. An intermediary (or 
client) that fails to do the right thing is broken, and a bug should be 
reported.

(I agree wrt 100 and 101, but these are not what I'm concerned about)

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

RFC 4918 does not deprecate 102; it just doesn't define it anymore (4918 
was the transition to Draft Standard, and we didn't want to include 
things that currently were not implemented). The status is the same as 
for, for instance, the PATCH method which wasn't in RFC 2616.

So no, the intent wasn't to discourage use of 102.

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

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?

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

Best regards, Julian

Received on Thursday, 17 July 2014 13:23:03 UTC