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

Re: #535: No 1xx Status Codes

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 2 Jul 2014 16:30:21 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E625A457-D979-4507-B453-49A5B0576A1D@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>

On 2 Jul 2014, at 4:25 pm, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2014-07-02 08:02, Mark Nottingham wrote:
>> On 2 Jul 2014, at 3:58 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
>>>> The feeling in the room in Seattle AIUI was that non-final status codes are a signalling mechanism that is no longer necessary in HTTP/2, since the framing layer can do a better job at these tasks. As such, we do not plan to accommodate non-final status codes (1xx) in HTTP/2.0, but instead will give advice about how they can be handled by intermediaries doing transitions between 1.x and 2.x (with one example above).
>>> That advice isn't there. What can an intermediary do with a new 1xx status code other than dropping it?
>> That was referring to the specific cases that are in use, not the class.
>> Can you compose a pull request outlining what you'd like to see, so we can get a sense of how intrusive it would be, and how likely it is that it'd be supported?
> I can give it a try in the next few days. Before I start, can we do a sanity check on this example?
>> A non-final response using a 1xx status code other than 100 or 101 is transmitted as a HEADERS frame, followed by zero or more CONTINUATION frames:
>>  HTTP/1.1 103 BAR                 HEADERS
>>  Extension-Field: bar       ==>     - END_STREAM
>>                                     + END_HEADERS
>>                                       :status = 103
>>                                       extension-field = bar
> So we'd just send multiple header frames except one.
> If this makes sense, the other change would need to be applied to 8.1:
>> An HTTP message (request or response) consists of:
>>    1. one HEADERS frame (followed by zero or more CONTINUATION frames) containing the message headers (see [RFC7230], Section 3.2), and
>>    2. zero or more DATA frames containing the message payload (see [RFC7230], Section 3.3), and
>>    3. optionally, one HEADERS frame, followed by zero or more CONTINUATION frames containing the trailer-part, if present (see [RFC7230], Section 4.1.2).
> to say:
> "0. zero or more HEADERS frames (followed by zero or more CONTINUATION frames) containing the message headers of non-final (1xx) HTTP responses (see [RFC7230], Section 3.2 and 6.2), and"

As long as that's contained to just responses, I think so.

An alternative resolution would be to mint a new, short consensus document that disallows minting new 1xx status codes -- due to the fact that they're not well-supported in implementations nor APIs, nor intermediaries (IIRC).


Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 2 July 2014 06:30:49 UTC

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