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

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

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Sun, 20 Jul 2014 21:13:53 +0000
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <32982.1405890833@critter.freebsd.dk>
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.

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 Sunday, 20 July 2014 21:14:16 UTC

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