Re: Upgrade status for impl draft 1

I think we're agreeing, then, pre-supposing that we're expecting an
HTTP/1.1 server on the other side.
-=R


On Fri, Feb 22, 2013 at 5:38 AM, Willy Tarreau <w@1wt.eu> wrote:

> On Fri, Feb 22, 2013 at 05:14:03AM -0800, Roberto Peon wrote:
> > 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.
>
> I agree on this last point, but this probably is where the magic can help
> if
> placed at the proper location. In WS, we refrained from sending anything
> along
> with the handshake. However there is nothing that prevents us from sending
> the
> upgrade and the magic in the same packet to validate that the channel
> really
> is open :
>
>  > HEAD * HTTP/1.1
>  > Host: foo
>  > Upgrade: HTTP/2.0
>  > Connection: Upgrade
>  >
>  > MAGIC-request
>  (first frame etc...)
>
>  < HTTP/1.1 101 Switching
>  < Upgrade: HTTP/2.0
>  < Connection: Upgrade
>  <
>  < MAGIC-response
>
> And then it makes a lot of sense to have a MAGIC-request above that
> should cause an abort on most systems (as Mark has been experimenting
> with), because as long as intermediaries are 1.1-compliant, they will
> correctly forward 2.0 to the end point without breaking the connection.
> The ones broken will only be the non-compliant ones.
>
> Willy
>
>