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

On Jul 20, 2014, at 2:13 PM, Poul-Henning Kamp wrote:

> In message <EAFC2172-B96D-4910-8A39-D609D3735314@mnot.net>, Mark Nottingham wri
> tes:
> 
>> Roy's point below hasn't been discussed in the context of HTTP/2 
>> before IIRC; he's right in that the nature of expect/continue in 
>> HTTP/1 is not just hop-by-hop. 
> 
> The problem is that you don't know what it is, and therefore it
> is not particular attractive to use it outside controlled
> environments.

We have one protocol definition and it is based on interoperability
among conforming implementations.

> 100-Continue would become much more attractive to use if HTTP/2
> made it end to end.
> 
> Obviously, we can not guarantee e2e if there are HTTP/1 nodes
> involved, but I still think it would be an improvement to make
> it e2e on pure H2 paths.

100 is already end to end unless one of the intermediaries is not
conforming to HTTP/1.1, which is accounted for in the protocol.

> My preferred solution is a HEADERS bit which says "I'll send
> the entity-body when you tell me to."
> 
> In order to not complicate things with new semantics we need to
> explain, I would make the "tell me to" part a WINDOW_UPDATE from
> the receiver on that stream.
> 
> If we go into the "send HEADERS with 100 :status" territory it will
> make the protocol semantics and description much more complicated.

It is far easier to just forward the 1xx status code.  After all,
the application is unlikely to know anything about h2/spdy, so it
will be waiting for the 100 Continue regardless.  The recipient's h2
protocol library will have to detect the hack and then translate
it into a fake 100 response for the application, which seems to be a
waste of effort.  In any case, framing hacks don't supplant the other
1xx status codes and are therefore not a solution to Julian's issue.

....Roy

Received on Tuesday, 22 July 2014 02:29:02 UTC