- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Thu, 17 Jul 2014 13:34:29 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In message <53C7CFC5.4080208@gmx.de>, Julian Reschke writes: >> I'm against adding a "contigency plan" to HTTP/2 on the unlikely >> probability that 103 will ever happen, given that 1xx already works >> like shit in HTTP/1. > >Are you referring to 100, 101, or other 1xx codes? All of the above. >> Nobody says we cannot add support for 1xx later, if it suddenly >> transpires to be a killer-app for something. > >Chicken-and-egg: if you can't use 1xx over HTTP/2, it's very unlikely >that that new status code 103 will ever be defined. And that would be perfectly fine with me: Imagine the hazzle anybody doing so would have to get it working with HTTP/1... >> In the meantime I propose we add a flag to HEADERS (ON_YOUR_SIGNAL >> ?) and give it the meaning "I'll send the body when you send me a >> WINDOWS UPDATE" and close the long sad saga of 1xx dysfunctionality. > >That's a problem specific to *100*. yes. 101 isn't needed if we sensibly declare that updates to HTTP/2 use the same frame structure. And 1xx apart from those two, I'll not even start to think about until somebody concretely tells us what they are for and what they should do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Thursday, 17 July 2014 13:34:54 UTC