Re: "Upgrade: h2c"

On Wed, Jul 16, 2014 at 09:04:06AM +0000, K.Morgan@iaea.org wrote:
> After reading through Section 3.2 'Starting HTTP/2 for "http" URIs' again, I
> have the following question, observation and suggestion regarding requests
> with an "Upgrade: h2c" header.
> 
> 
> 
> *Question: Is it possible to pipeline?*
> 
> It seems to me that it is impossible to pipeline requests with an 'Upgrade'
> header without possibly causing problems.  If the server switches to h2c,
> pipelined HTTP/1.x requests will be parsed as h2c frames and obviously cause
> errors.  On the other hand, if the server doesn't switch to h2c and the
> client tried to pipeline h2c requests, that will also cause errors.

The "PRI * HTTP/2.0" preface is there to ensure that the data that follows
the upgrade request is not accidentely confused with a second H/1 request.

Anyway I think that pipeline will not be used with Upgrade just for the
same reason it's rarely used in HTTP/1.1 : too many bogus implementations
in field.

> *Observation: Two responses?*
> 
> When the server accepts the "Upgrade" and switches to h2c, it seems a bit
> bizarre that two responses are sent in response to the original HTTP/1.x
> request with the "Upgrade" header.  1) the "101 switching protocols" HTTP/1.x
> response, and 2) the h2c response on stream 1 for the URL in the original
> request.  What happens with "101" responses for other upgrade protocols e.g.
> WebSockets?  Does the original request have any semantic meaning once the
> switch is made?

It's not two responses, 1xx are interim responses, they indicate that the
final response is coming after (possibly in a different form in the case
of 101/switching).

For WebSocket it's the same, the rest of the communication is considered as
the final response to the Upgrade request. It's just that the response is
made using the WebSocket protocol.

Willy

Received on Wednesday, 16 July 2014 09:32:40 UTC