- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 15 Jul 2014 18:13:05 +1000
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 2 Jul 2014, at 4:40 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2014-07-02 08:30, Mark Nottingham wrote: >> ... >> 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). >> ... > > Do you have evidence of implementations that break on new 1xx codes? > > I agree that APIs are a problem, but we have the same problem for trailers (which we keep), and anything that's new in the HTTP/2 world will need new APIs as well, so I'm not sure how that is a compelling argument. I think it's a decision that needs to be weighed on its merits; there is no single rule that we can apply to make all decisions (as much as I would enjoy automating the WG). My .02 - Status codes have semantic "heft" in the protocol, and if an entire class of them is both poorly supported and has poor interest, it's not unreasonable to consider deprecating that class of status codes. If someone tries to use it in the future, they're going to be disappointed, because it isn't supported in software and APIs; that semantic won't be useful to express or expect (as was found with 102). Persisting 1xx status codes has a real cost; besides the obvious cost of requiring HTTP/2 implementations to code for them, test them, and support them, there's also the cost of handling the interoperability problems when they don't work. OTOH the benefit of keeping them is quite nebulous; the two 1xx status codes originally defined ended up being a lot of trouble (100) and unused (101), and the only further one defined (102) turned out to be deprecated because of lack of support. So, my take is that making HTTP/2 more complex to satisfy use cases that haven't materialised in almost 20 years doesn't seem like a good tradeoff. Re: Trailers - I don't think that we should use them as an exemplar for the features we put into HTTP/2; they barely made it in, and they are explicitly ignorable in HTTP/1. Personally, the argument you're making drives me to want to remove trailers, not add 1xx. How do other folks feel about this? We can talk about it in Toronto, of course. -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 15 July 2014 08:13:36 UTC