- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 02 Jul 2014 07:58:31 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2014-07-02 07:39, Mark Nottingham wrote: > > On 27 Jun 2014, at 7:20 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > >> On 2014-06-27 09:56, Mark Nottingham wrote: >>> <https://github.com/http2/http2-spec/issues/535> >>> >>> This seems like a re-opening of <https://github.com/http2/http2-spec/issues/264>. We discussed it a fair amount in the Seattle interim, and there was pretty strong support in the room for getting rid of 1xx status, especially since they're poorly supported in implementations, almost non-existant in APIs, and often don't survive hop-to-hop. >>> >>> Julian, anything to add? I'm inclined to close this as a duplicate unless there's significant new information... >> >> I still fail to see a compelling reason to remove them. >> >> Why do we keep trailers, but not 1xx? I'd like to understand how we draw the line. > > My .02 - trailers work in a way where they may not get used much, but some people still find them useful, and they don't cause significant issues. > > 1xx, OTOH, has a track record of causing considerable havoc, and as has been pointed out many times, its semantics are better expressed in the framing layer. The status code *class* hasn't caused any havoc at all (unless I'm missing something), and expressing the semantics in the framing layer implies you need two different ways to express the semantics for 1.1 and 2. > That said, it's very much a judgement call. When we made that decision, we discussed it both in an interim and on the list: > http://www.w3.org/mid/D630DC2F-1FBF-4824-AE5E-1CF81F65DD03@mnot.net > ... and there was considerable support for -- and no pushback against -- doing it. > ... While some people were busy getting six RFCs through IESG review :-) I'll also cite: > 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? Best regards, Julian
Received on Wednesday, 2 July 2014 05:59:06 UTC