W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Upgrade status for impl draft 1

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 21 Feb 2013 15:59:34 -0800
Message-ID: <CABkgnnXSf0SJ-aTVUUtQwzn2Z1rFS9TzYAdA4ORriMKV8cfCkg@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I took the liberty of drawing up a few pictures:

http: URI Upgrade
http://www.websequencediagrams.com/?lz=dGl0bGUgSFRUUC8yLjAgVXBncmFkZQoKQ2xpZW50LT5TZXJ2ZXI6IFRDUCBTWU4KAAoGLT4AGgYADwksQUNLAB8VAAQUAGkFMS4xIEdFVCArAGsJAEsQAB4JMTAxAAcgMi4wIE1hZ2ljICsgU0VUVElOR1MKbm90ZSByaWdodCBvZiAAgUIIAIFMBiBzZW5kcyBmaXJzdCBpbgCBeQkhAEYaMjAwAIE1FgBpFA&s=napkin

https: (I didn't distinguish between magic/no magic)
http://www.websequencediagrams.com/?lz=dGl0bGUgSFRUUC8yLjAgVExTCgpub3RlIG92ZXIgQ2xpZW50IFNlcnZlcjogVENQIENvbm5lY3RlZAoAFwYtPgAVCUxTACoHSGVsbG8KADAGLT4APwYAGgYARAYAGgYALBRG

Sure, you could drop the magic if you've negotiated the protocol in
the TLS handshake, but it doesn't seem that useful and it creates an
extra if() statement.

What I didn't realize was the consequences of permitting the response
to the HTTP/1.1 request to be sent immediately.  In the Upgrade, the
server sends first on the HTTP/2.0 session.  This has implications for
several things (flow control, suppressing server push, etc...).

On 21 February 2013 08:50, Martin Thomson <martin.thomson@gmail.com> wrote:
> I took some different conclusions away:
>
> Specifically, I believe that we discussed having magic always
> regardless of how we got started, so that there was only one code
> path.  That wasn't firm, but I distinctly remember the conversation
> that lead to that conclusion.
>
> We didn't conclude on whether we would always need upgrade, though it
> was evident to me that avoiding upgrade was clearly desirable: see
> https://github.com/http2/http2-spec/issues/29
>
> On 21 February 2013 01:11, 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
>>
>> The decision as to whether to use 2(a) or 2(b) in a particular situation is up to implementations, but of course we'll give (non-normative) guidance.
>>
>> Does this make sense to everyone?
>>
>> Regards,
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
Received on Friday, 22 February 2013 00:00:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 February 2013 00:00:04 GMT