Re: #385: HTTP2 Upgrade / Negotiation

On Mon, Oct 22, 2012 at 7:03 PM, Mark Nottingham <mnot@mnot.net> wrote:

> [snip]
>
> 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.
>
>
Such a dedicated default port definitely needs to be defined. There are
many scenarios where upgrade negotiation simply is not going to be required
at all.


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

Defining a new dns record type would be unnecessary and would be the wrong
approach. SRV records were made specifically for this kind of use. They're
certainly not perfect but inventing a new record type specifically for
http2 stuff is even less so.


>
> 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.
>
>
This is one of those ideas that sounds interesting in theory but I don't
see how it would be effective in practice.


> And, are there any other approaches we want to put on the table?
>
>
For browsers, upgrading on the first connection is obviously going to be
critical. The DNS option seems like the best approach for the most general
case, despite the various flaws in that approach.
montenegro-httpbis-http2-negotiation seems to provide a reasonable fallback
when we're talking primarily about GET/HEAD traffic, but it has obvious
issues when dealing with POST/PUT/PATCH type operations. I do not really
want to always have to send PUT requests as HTTP/1.1 when what I really
want is to use HTTP/2.0 for the entire flow. For payload-bearing requests,
upgrade needs to be negotiated before the initial request is sent.

One possible way to mitigate this would be to combine the Upgrade header
approach with a new Expect token. For instance...

  POST /default.htm HTTP/1.1
  Host: server.example.com
  Connection: Upgrade
  Upgrade: HTTP/2.0
  Expect: 101-upgrade

The addition of the Expect header does two things...

1. It makes the upgrade a requirement rather than optional...
2. The client would then wait as reasonable time for the 101 Switching
Protocols before it proceeds to send the http/2.0 encoded data...

When the client does start sending the data (after receiving the 101
response), it would do so by first sending a SYN_STREAM.. To http/1.1
servers, this would appear to be nothing more than regular POST payload
data. For http/2 traffic, this requires an initial round trip but it
addresses the upgrade on payload-bearing request issue... and is exactly
the kind of thing the Expect header was intended for. The scheme is
obviously far from perfect, however.

Alternatively, I firmly believe that a http2 URI scheme as a reasonable
fallback needs to be considered as an option here... particularly if we do
define a dedicated http/2 default port. Yes, I agree with the whole "we
want to do existing http:// and https:// traffic over http/2 transparently"
argument and fully understand the challenges of introducing a new URI
scheme. However, there will be instances where upgrade negotiation is
simply not going to be necessary and for which backwards compatibility with
existing infrastructure is going to be unnecessary. For those cases, the
ability to pass a URL like "http2://example.org" and have it just
automatically understood that it's "http/2 over port whatever" will be
extremely useful. A no brainer even. So much so that if the working group
here doesn't choose to define it, I'll likely just end up writing it up as
an individual submission. That way, when I write.. <form method="post"
action="http2://example.org">...</form> the notion that http/2 is being
used is explicit and no upgrade discovery/negotiation is required at all.
That's what url schemes are for in the first place, right?

- James



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