Re: [hybi] GET+Upgrade as emended by Greg (was Re: handshake status)

[Zhong Yu <[e-mail]>]

On Thu, Nov 11, 2010 at 12:42 AM, Willy Tarreau <[e-mail]> wrote:
> On Tue, Nov 09, 2010 at 05:34:05PM -0600, Zhong Yu wrote:
>> On Tue, Nov 9, 2010 at 4:12 PM, Greg Wilkins <[e-mail]> wrote:
>> > Guys,
>> >
>> > we really need to break this down.
>> >
>> > The PRIMARY purpose of my proposal was to fix the problem with
>> > intermediaries poorly handling the unframed bytes.
>> > The SECONDARY purpose of the proposal is to provide a fast fail
>> > mechanism to check that a connection can send/receive WS frames (by
>> > actually sending/receiving WS frames).
>>
>> I really like that. (although I think it's ok for client to send a WS
>> frame first)
>
> Yes it is OK for a client to send the WS frame first, however most will
> refrain from doing so because if the request fails (eg: authentication),
> they have to close the connection because of the already sent data which
> have polluted the connection. That's why while in theory, having the WS
> client send the frame first avoids one round trip, in practice it will
> not because browsers won't use that optimization.
>
> That's the same as with CONNECT through proxies. Browsers are free to
> send their HTTPS request just after the CONNECT request to save one
> round trip, but in practice they don't and prefer to wait for the 200
> response to ensure they can use the connection.
>

The client Hello WS frame I was talking about is part of the handshake
that helps to determine whether the connection is usable for WS. The
WS client should send it in the same packet of the HTTP handshake
stuff.

I am also under the impression that a WS connection is always a new
connection. A previous HTTP connection will never be re-purposed by
browser for WS. A WS connection will never be re-purposed by browser
for HTTP.

- Zhong Yu