#1: Upgrade Mechanism

<https://github.com/http2/http2-spec/issues/1>

To make sure everybody is in sync -- We've been discussing HTTP/1 (without TLS) negotiation for some time.

Currently, the draft documents one method of doing this, using Upgrade:
  <http://http2.github.io/http2-spec/#discover-http>

Recently, we've also been discussing using Alt-Svc for this (as distinct from the opportunistic encryption case):
  <http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-00>
  
Both of these were discussed in the Vancouver meeting:
  <http://tools.ietf.org/wg/httpbis/minutes?item=minutes-88-httpbis.html>
(search for "#### Issue 1: Upgrade Mechanism")

There, we stated an intent to leave the Upgrade mechanism in and get implementer experience, and also reference Alt-Svc and get experience with that as well. Neither is required.

We've also talked in the past about DNS-based negotiation, but we haven't yet landed on an approach that we've seen implementer interest in (although Patrick has said that he wants to do some experimentation and bring the results back to us).

I would characterise the overall approach as documenting the fewest number of negotiation mechanisms we think are necessary, acknowledging that there are a variety of use cases with HTTP with potentially different requirements. 

So, just a suggestion -- it would probably be most productive if you have a look at those and make proposals for changes / questions, etc. based upon those, since they reflect the current state of discussion. If you don't think they're the right approaches, you might want to consider writing an I-D proposing a different one.

Cheers,


On 21/11/2013, at 7:12 AM, Michael Sweet <msweet@apple.com> wrote:

> Yoav,
> 
> On Nov 20, 2013, at 2:50 PM, Yoav Nir <synp71@live.com> wrote:
>> ...
>> That info will be interesting. I worry, though, that it's a huge undertaking to get a complete picture because of the long tail.
> 
> I’m less concerned about getting a 100% complete picture and more wanting to get a general picture based on proxies that are popular and/or known to have issues.
> 
> I am under no illusion (delusion? :) that we will be able to do HTTP/2.0 upgrade over current proxies.
> 
> Rather, I want to know whether a HTTP/2.0 client can successfully continue to function with HTTP/1.1 proxies - can we reliably either a) know that we can attempt an upgrade or b) recover from a failed upgrade?
> 
> Answering those questions will determine whether it is feasible to support plain text HTTP/2.0 on port 80 and/or whether we would really need a new URI scheme to differentiate between HTTP/1.x and HTTP/2.0.  I’m hopeful that the answer is actually *yes* since the “failure” mode for HTTP/2.0 upgrades is just using HTTP/1.1, vs. WebSockets and other similar extensions that rely on upgrade to work at all.
> 
> In short (and I apologize for paraphrasing): Failure IS an option.  We just need to know *how* HTTP/2.0 upgrade will fail to determine if it would prevent implementors from supporting plain text HTTP/2.0 over the Internet.
> 
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 

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

Received on Wednesday, 20 November 2013 23:12:37 UTC