- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 2 Jul 2014 16:30:21 +1000
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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). Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 2 July 2014 06:30:49 UTC