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

On Sun, Jul 20, 2014 at 4:13 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> 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.
>
> 100-Continue would become much more attractive to use if HTTP/2
> made it end to end.

What is the end-to-end semantics though? As far as the application is
concerned, the request-response cycle has the same semantics whether
or not 100-continue is exchanged under the hood. Whether or not the
server can process the request without knowing the body does not rely
on the presence of 100-continue, and is not an interesting information
that has to be revealed, except for the purpose of optimization.

Zhong Yu
bayou.io

>
> 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.
>
> 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.
>
> --
> 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 Tuesday, 22 July 2014 03:36:46 UTC