Re: #385: HTTP2 Upgrade / Negotiation

[William Chan (陈智昌) <[e-mail]>]

Overall, sounds good. I've included some clarifications/questions below.

On Mon, Oct 22, 2012 at 7:03 PM, Mark Nottingham <[e-mail]> wrote:
> <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)?

Do you mean the Chromium HTTP upgrade experiment agl referred to in
http://www.ietf.org/mail-archive/web/tls/current/msg05593.html?

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

I'm not sure if my previous emails were taken to indicate "interest"
here. I forget what I said too :) As long as this is more of an
optional optimization than anything, I guess I'm OK with it. I'm very
much concerned about relying on it, due to experiments we have run
with TXT records that show us noticeably higher failure rates in
comparison to port 443, higher latency (we'd definitely have to race
this), and extra DNS queries.

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

Just to be clear, SRV records also have the disadvantage of not
upgrading the first interaction, unless you block on the response,
which Chromium definitely is not going to do unless the environment
changes such that it doesn't kill performance.

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