- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 21 Feb 2013 15:59:34 -0800
- 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 UTC