Subject: "Upgrade: h2c"

From: <[email-masked]>
Date: Wed, 16 Jul 2014 09:04:06 +0000

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.

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

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?

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 16 Jul 2014 11:32:16 +0200

On Wed, Jul 16, 2014 at 09:04:06AM +0000, [email-masked] 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.
> 
> 
> 
> 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.

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Jul 2014 20:01:08 +1000

Keith,

Please read:
  http://httpwg.github.io/specs/rfc7230.html#header.upgrade

Cheers,

On 16 Jul 2014, at 7:04 pm, [email-masked] wrote:

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

--
Mark Nottingham   http://www.mnot.net/

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 10:25:22 +0000

Hi Mark & Willy-

Thanks for the information and link.  I didn't realize that Section 3.2 was following the guidelines in RFC 7230.

I still think it would be useful to allow the client to _speculatively_ include "pipelined" h2c requests in a HTTP2-Frames base-64 encoded header which would include a required settings frame and 0 or more optional HEADERS frames: SETTINGS HEADERS*

What do you think?

I'm also curious what the _Microsoft_ guys think since they are apparently the only browser that will support "Upgrade" to h2c.

-keith

---

From: Michael Sweet <[email-masked]>
Date: Wed, 16 Jul 2014 08:05:38 -0400

> 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 h…

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".

> 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 sw…

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…

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 13:26:22 +0000

Hi Martin-

> coming - I don't see that as confusing.

Yes.  Sorry.  I understand that now - shows my ignorance regarding 1xx codes (or lack of experience therewith).

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

Yes, I also understand that now.  In my follow-up e-mail I changed my suggestion to be "HTTP2-Frames: b64(SETTINGS HEADERS*)".

The benefit would be that in addition to the initial request (which, as you point out, has its headers in the HTTP/1.x request), the client could speculatively pipeline h2c requests for other resources (e.g. on a browser restart).

Otherwise the client has to wait 1 RTT before it can send any more requests.

This might be particularly useful if the client knows it is likely the server will accept the "Upgrade" to h2c e.g. it accepted an upgrade in the past.

-keith

---

From: Rob Trace <[email-masked]>
Date: Thu, 17 Jul 2014 00:37:01 +0000

Hi Keith,

We do not support Pipelining so this is a non-issue for us.

Thanks!!

-Rob

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 16, 2014 3:25 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Rob Trace; Osama Mazahir; Mike Bishop; Gabriel Montenegro; Brian Raymor (MS OPEN TECH)
Subject: RE: "Upgrade: h2c"

Hi Mark & Willy-

What do you think?

-keith