#385: HTTP2 Upgrade / Negotiation

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/385>

This issue is how we upgrade from 1.x to 2.x. I'd suggest we consider the issue in two parts, for HTTPS URIs and HTTP URIs. Furthermore, we need to figure out how we'll identify the protocol that's in use as we develop it.

HTTPS URIs
==========

Based on previous discussion and our charter, I think the path forward for negotiating HTTP/2.0 for https:// URIs is pretty clear; we need to make a request to the TLS Working Group, asking for a in-protocol negotiation mechanism for the "next" protocol to use.

The question for us right now is what requirements we want to place upon that work. Currently, I have:

---8<---
TLS Working Group Chairs,

This is a request from the HTTPbis Working Group for you to commence work upon a mechanism that allows clients and servers to negotiate the particular application protocol to use once the session is established.

Our use case is for HTTP/2.0 in conjunction with HTTP URIs; rather than defining a new port, which incurs both performance and deployment penalties, a negotiation mechanism would allow for better deployment of HTTP/2.0 for HTTPS URIs.

We would expect such a mechanism to allow the client and server to negotiate the use of one of potentially many such protocols (in our case, HTTP/1.x and HTTP/2.x), identified by tokens, and falling back to a default for the port in use (in our case, HTTP/1.x) when either side doesn't support negotiation, or an agreement can't be found.

We also note existing work in this area:
  http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04

The HTTPbis Working Group will be happy to coordinate schedules, review drafts and provide further input as required.

--->8---

Does anyone have further input? I'd like to get the request to the TLS WG very soon.


HTTP URIs
=========

For HTTP URIs, the field is much more open.

I think the basic requirement is that it be possible to negotiate use of:
  - HTTP/1.x
  - HTTP/2.x
  - HTTP/2.x over TLS, possibly with caveats around cert checking, etc.

for HTTP URIs. Note that we may or may not define the third "mode", but the negotiation mechanism needs to be able to accommodate it, as per our charter.

There are a *lot* of ways this could happen. 

One suggestion has been made by Gabriel and Willy:
  http://tools.ietf.org/html/draft-montenegro-httpbis-http2-negotiation-00
... which is basically a good explanation of how HTTP Upgrade was intended to work. Notably, it does not introduce a roundtrip. 

One of the major perceived issues with this approach is interference by broken proxies (i.e., those that don't honour the hop-by-hop status of Upgrade). 

I know that some experiments were done with this in the HYBI work, but I'd like to do some more, to get an idea if it's possible to mitigate some of this risk (e.g., by sending "Connection: Upgrade"). Based upon that, we can make an informed decision about this approach.

Who's willing to do some experimentation? Specifically, does anyone have access to the code that was used before (IIRC, people bought some ads and inserted some Java to probe the network)?

Other approaches suggested as alternates and/or compliments to this include:

1) Using a SRV (or other DNS) record. There seems to be a fair amount of interest in this from the browser implementers; the only resistance seems to be around how hard this would be to deploy, but if it's not the only mechanism for upgrading to HTTP/2, it shouldn't be a concern. 

Presumably, we'd define a default port for HTTP/2-only communication when used in conjunction with this, so that firewalls would know to open it, etc.

Does anyone object to us defining such a record (type TBD), as long as it's not the only way to get to HTTP/2 for HTTP URIs?

2) Using a response header to hint that HTTP/2 is available on another port. 

This approach hasn't been talked about in detail yet, but it apparently (as some have noted) has the disadvantage of not upgrading the first interaction, and of requiring a separate cache (and caching model) for this information.

Who wants to pursue this approach? If so, we need a small proposal written, preferably as an I-D, but an e-mail would do.

And, are there any other approaches we want to put on the table?


Identifying The Protocol in Development
===============================

Finally, I'd like to make sure we understand how we're going to identify this protocol as we move forward.

The NPN, Upgrade and Alternate-Protocol approaches all (should, if we go there) use a token to identify the protocol being upgraded to, meaning that we'll be able to do something like

  http2-draft-3
  http2-draft-5

when negotiating the protocol while we're developing it; as long as implementations deploy the latest version and perhaps the one before it, they should be able to interoperate, and fall back to HTTP/1 if not. The browsers have used this approach for SPDY, and it seemed to work well.

To me, this implies that if we define a DNS-based mechanism to hint upgrade, it should have a similar capability, so we can reuse those tokens and this approach there too. Make sense?

Concurrently, the SPDY draft uses 15 bits to identify the protocol in use. Provided we get the upgrade mechanism right, I'm less concerned about this, but it would be good if the messages were self-describing, so we should figure out what the appropriate values to put in here are too. And, maybe saving a few bits too.

Cheers,


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

Received on Tuesday, 23 October 2012 02:03:55 UTC