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

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

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Mon, 21 Jul 2014 22:36:19 -0500
Message-ID: <CACuKZqEQE3xQ=fdXCwx6k+7Gu9N9LikZg26TKXEXSnGO+jjg0g@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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

> 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

This archive was generated by hypermail 2.3.1 : Monday, 18 November 2019 18:02:00 UTC