Re: "Upgrade: h2c"

On Jul 16, 2014, at 5:04 AM, 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.

RFC 7230 doesn't say anything explicitly about this, but since the subsequent requests would not be processed by the server until the upgrade was completed, I would say "no".

> *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?

You're getting a 1xx status code, which always means that another response is coming - I don't see that as confusing.

And as for the upgrade, the server's 101 response includes an Upgrade header that says which upgrade is being performed; conceptually you could have a client request TLS and WebSockets upgrades, and the server could provide two intermediate 101 responses (first for TLS, then for WebSockets/whatever) before providing a final response to the original request.

I'm not aware of any implementations of multiple upgrade, however.

> Currently we have a "HTTP2-Settings" header for sending the required HTTP2-Settings frame that initiates the connection. Would it be possible to add or replace "HTTP2-Settings" with a "HTTP2-Frames" header that includes a base-64 encoded value of the following frames: SETTINGS HEADERS+. Where HEADERS+ includes the first request hpack-encoded plus any *speculative requests* the client wants to pipeline in anticipation of the server switching to h2c?

Since the initial HEADERS come from the HTTP/1.x request, what purpose would that serve?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair