- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 5 Sep 2013 05:14:26 -0700
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
On Sep 5, 2013, at 1:29 AM, Amos Jeffries wrote: > 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. Right, we cannot rely on the client receiving the 100 or 101 before it starts sending the body data. In any case, it is very unlikely that a client's first request to a server is a big POST. ....Roy
Received on Thursday, 5 September 2013 12:14:48 UTC