- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 22 Feb 2013 15:51:13 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 22/02/2013, at 3:50 AM, 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. Works for me; I'm more interested in just getting something concrete written down. Anyone have a problem with that? One thing we need to discuss is how servers should handle it when the magic isn't sent, or isn't sent correctly; hard close? Also, we haven't concluded on server->client magic. Do we have a real need for it? > 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 My sense is that requiring it is going to be a non-starter. That's why I proposed three distinct paths below. Cheers, > > 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/ >> >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Friday, 22 February 2013 04:51:39 UTC