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

Re: Getting to Consensus on 1xx Status Codes (#535)

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>
Message-ID: <18951.1405604069@critter.freebsd.dk>
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

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