W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Jul 2014 14:02:18 +0200
Message-ID: <53C7BB4A.3020409@gmx.de>
To: Michael Sweet <msweet@apple.com>, Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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?

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

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

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

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

Best regards, Julian
Received on Thursday, 17 July 2014 12:02:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC