Re: HTTP/2 Upgrade with content?

On 13/03/2015 10:42 p.m., Ilari Liusvaara wrote:
> On Fri, Mar 13, 2015 at 04:28:46AM -0400, Jason T. Greene wrote:
>> What about draining the content and after the 101 the h2 response
>> sends a 307?
> 
> Might work if you never send a 100 (including implicitly by waiting
> too long). 100-Continue may mean that the data transfer can't
> be retried after it starts.
> 
> And if the client app is has simplistic redirect checking (just
> count redirects), one could even 307 to self...
> 
> 
> I.e, as flow:
> - POST to foo (with upgrade to h2c and 100-expect)
> - 101 to h2c
> - 307 to foo

missing:
 - <complete payload in 1.x format dumped into the pipe>

> - POST to foo (with 100-expect)
> - 100
> - <payload>
> - 200
> 
> 
> -Ilari
> 

No matter what you do the client has started sending a request specifid
as having a payload in HTTP/1 format. It must finish that request,
including the payload it promised, before any HTTP/2 may happen.
 - if the client is smart it would use chunked encoding then abandon
with 0-sized chunk on seeing the 30x. But that has other nasty problems,
and servers cant rely on it.

All these 30x tricks do is allow you to bit-bucket the 1.x payload
before moving on to the hopefully repeated 2.0 format one. It still
"blocks the connection" while the drain is happening - which may be GB
or TB of bandwidth and duration.

We have some prior painful experience applicable from NTLM vs POST
requests. In all cases there is large bandwidth wastage and latency.


However, that "blocking the connection" only means that the *client*
can't send other requests in parallel or h2 control frames. The server
is still free to PUSH_PROMISE etc. about what will follow once that 1.x
payload is done.


IMHO its actually simpler to implement a 1.1->2.0 converter and use it
as if it were a bit-bucket handler for the initial payload than to
handle all the edges cases involved when avoiding 1.x. Still not nice,
but simpler than any fancy dances with a mandatory bit-bucket anyway.


There is also the possibility of just using 2.0 natively from the start.
Manual tools and web apps with server knowledge should have no problems
just using 2.0 when they know the other end is.


Amos

Received on Friday, 13 March 2015 10:43:52 UTC