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

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

From: Michael Sweet <msweet@apple.com>
Date: Thu, 17 Jul 2014 09:30:19 -0400
Cc: Julian Reschke <julian.reschke@gmx.de>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <0355A0F3-2FCC-4713-9851-1867529B76F8@apple.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
I'd just call the flag "EXPECT_WINDOW_UPDATE" and document that it corresponds to the Expect: 100-continue semantics of HTTP/1.1.

We'll still need to define the HTTP/1.1 gateway behavior, e.g., a 2.0 to 1.1 gateway needs to implement a timeout that sends a WINDOW_UPDATE frame if it doesn't see a 100 response in a timely manner.

On Jul 17, 2014, at 9:14 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> In message <53C7CAD4.6080909@gmx.de>, Julian Reschke writes:
>>> We can do 100 better, don't need 101 and we have no idea how any
>>> future 1xx codes might or might not work anyway.
>> The last part doesn't make any sense.
>> My proposal is to treat them *exactly* as in 1.1.
>> What exactly do you mean by "might or might not work"?
> We've seen only one new additional 1xx code in ages and we already
> regretted it.
> 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.
> Nobody says we cannot add support for 1xx later, if it suddenly
> transpires to be a killer-app for something.
> 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.
> -- 
> 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.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Thursday, 17 July 2014 13:30:51 UTC

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