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

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