Re: Upgrade status for impl draft 1

Adding the upgrade, etc, to the mandatory magic (instead of treating the
UPGRADE as something for/from HTTP/1) is getting the bytecount large enough
to be noticable, btw, and may be getting into performance impacting areas.
Of course this is totally guesstimation and only time (and thus data) will
tell.
-=R


On Fri, Feb 22, 2013 at 5:41 AM, Roberto Peon <grmocg@gmail.com> wrote:

> 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
>>
>>
>