Re: Upgrade status for impl draft 1

Are you proposing following normal Upgrade semantics (that would add an RT,
bleh).
The magic which we have now is intended to make noncompliant intermediaries
barf. We know that Upgrade doesn't work particularly well for this from WS
experimentation, and a successful Upgrade (as viewed from the server's
perspective) doesn't necessarily mean that you're free-and-clear to talk in
the next protocol.

So, if you're doing an HTTP/1 upgrade, you'd do that, and then do the
HTTP/2 magic, and then proceed with the SETTINGS frame, etc.
I suspect you may be saying roughly the same thing??
-=R


On Thu, Feb 21, 2013 at 11:02 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Feb 21, 2013 at 08:11:08PM +1100, Mark Nottingham 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?
>
> I'm still having a problem with the principle behind 2b : when you
> pass through transparent intercepting proxies, by definition you're
> not aware of it. So even if 2a worked for the first connection, it
> does not preclude that 2b will work for the second one. Nor the DNS
> will BTW.
>
> And the issue I'm seeing is that 2b will require HTTP/2->2 proxies to
> be deployed along all the path for this to succeed. If 2->1 proxies
> are deployed, then we lose all benefits for 2.0 by terminating the
> optimizations close to the client. Let's consider the following
> common path :
>
>   [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]
>
> ISP proxy is the transparent proxy/cache at the client's ISP's, and SRV
> proxy is the ADC on the server side. Eventhough the server side is fully
> 2.0 compatible and advertises it via the DNS, until the ISP proxy is not
> a true 2.0->2.0 proxy, we'll have the following possibilities :
>
> Upgrade connection : creates a tunnel between CLI and server, end-to-end
> 2.0 (just like with TLS) :
>           2.0                      2.0                      2.0
>   [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]
>
> Magic, ISP proxy not aware at all : second connection fails, client has
> to fall back to 1.1 (or switch back to Upgrade ?) :
>           1.1                      1.1                      1.1
>   [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]
>
> Magic, with ISP proxy being a 2.0-to-1.1 gateway :
>           2.0                      1.1                      1.1
>   [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]
>
> Magic, with ISP proxy being a 2.0-to-2.0 gateway :
>           2.0                      2.0                      2.0
>   [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]
>
> The last case (2.0-to-2.0 gateway) will not happen soon, and I really
> believe that because of this, we'll be much more often in second then
> third case above where 1.1 only is used on the long path.
>
> Likewise, it is not said how such 2.0 should pass through explicit proxies,
> while the Upgrade provides such a solution.
>
> Why not consider the Upgrade request the "magic" itself ? In fact it's
> exactly that. I understand the complexity that the Upgrade can cause if
> we require the server to process the early requests in 1.1. But if we
> consider that it's just a prefix, there is no "dance" at all. It's just
> the same as what was proposed in 2817 for TLS upgrade, we connect to the
> other endpoint and establish a tunnel. No need to support multiple setup
> methods.
>
> Regards,
> Willy
>
>
>