Re: Upgrade status for impl draft 1

On 27/02/2013, at 2:43 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> I agree with the outcome of this thread (always requiring magic).

OK, I think that's where we're at. I've recorded the modified plan in the issue:
  https://github.com/http2/http2-spec/issues/1

I think this also resolves:
  https://github.com/http2/http2-spec/issues/29
... because it's clear that we're not dancing in 1 or 2(b). We will need some guidance on when to use 2(a) vs. 2(b), of course.


> On Thu, Feb 21, 2013 at 1:11 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Based upon discussion both at the Interim and subsequently, this is where I think we are for the upgrade/negotiation process, at least in terms of the 1st implementation draft:
> 
> 1. HTTPS URLs
>    - use NPN (or its replacement); uses OPAQUE TOKEN to negotiate
>    - NO magic
>    - SETTINGS first
> 
> 2. HTTP URLs
> 
>   a. existing connection / new connection without context
>       - Upgrade Dance; uses OPAQUE TOKEN to negotiate
>       - NO magic
>       - SETTINGS first
> 
>   b. new connection with context (e.g., because you used DNS hint, header hint, prior knowledge)
>      - NO upgrade dance
>      - Magic
>      - SETTINGS first
> 
> QQ over here. Is this assuming only unencrypted HTTP/2? I believe Patrick was hoping to bootstrap serving http:// URLs via HTTP/2 over SSL, using the external discovery mechanism (DNS most likely). If so, I'm unclear on whether or not we need to describe behavior WRT TLS-NPNesque negotiation. Perhaps we should fork the thread for this...

Well, I think that's orthogonal, in that you're still going to not do the dance, and send the magic, and send settings first.

I'd like to see our spec show a handful of ways to start a new connection (acknowledging that it's an open-ended set; i.e., someone may one day decide to support starting HTTP/2 using a different mechanism, especially if it's not TCP underneath), which includes negotiating the profile in use, and sending the magic. Whatever the TLS WG defines will be one of those mechanisms, but we still have to define how to use it in the scope of our protocol (just as we need to define how TCP is used, for example).

Cheers,

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

Received on Wednesday, 27 February 2013 05:46:32 UTC