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

Re: Expect: + Upgrade: = ...

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 05 Sep 2013 20:29:53 +1200
Message-ID: <52284101.9060803@treenet.co.nz>
To: ietf-http-wg@w3.org
On 3/09/2013 9:53 a.m., Daniel Stenberg wrote:
> Hi all,
> Suppose a client would do an HTTP POST to a http:// server that 
> supports HTTP 2.0, and it would send both an "Expect: 100-continue" 
> _and_ an "Upgrade: HTTP/2.0" header.
> Should we make it so that if a 101 is responded first, the rest of the 
> POST upload should be done using HTTP2 but if we instead get a "100 
> continue" first, we go on and send the data using HTTP?
> I guess another way would be to just not send both headers in the same 
> request! =)

I do not think so. If for any reason the client sends Expect then the 
payload anyway (happens) or times out and starts sending anyway before 
101 arrives you will end up with a corrupted HTTP/2 data flow and be 
worse off than just using HTTP/1. Particularly since this client is 
already signalling it wants to use the HTTP/1.1 fairly efficiently.

IMO when retaining that payload as HTTP/1 it is reasonable to expect 
either one to come back. Order does not matter due to the directionality 
of the traffic. In fact keeping it as HTTP/1 chunked will allow the full 
use of bandwidth of the connection to maximise speed reaching the end of 
it and be no less efficient than a HTTP/2 connection with single request 
on it sending DATA frames.

Note that Upgrade is specifying that the *response* will be in HTTP/2 
format. Expect: is specifying that the *request* payload will be 
delayed. RFC 2616 indicates that the HTTP/2 traffic from client only 
begins after that request (including payload) is completed.

Received on Thursday, 5 September 2013 08:30:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC