Re: [hybi] Experiment comparing Upgrade and CONNECT handshakes

[Adam Barth <[e-mail]>]

On Sat, Nov 27, 2010 at 10:00 PM, Scott Ferguson <[e-mail]> wrote:
> Ian Fette (イアンフェッティ) wrote:
>>
>> On Sat, Nov 27, 2010 at 8:24 AM, Adam Barth <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>    On Sat, Nov 27, 2010 at 8:16 AM, Willy Tarreau <[e-mail]
>>    <mailto:[e-mail]>> wrote:
>>    > On Sat, Nov 27, 2010 at 07:51:17AM -0800, Eric Rescorla wrote:
>>    >> What's the argument *for* having an insecure handshake?
>>    >
>>    > There's no argument *for* having an insecure handshake, there
>>    are arguments
>>    > for having a safe HTTP-compliant handshake.
>>
>>    The handshake we're proposing is both safe and HTTP compliant.
>>
>>    Kind regards,
>>    Adam
>>
>>
>> I really appreciate all the work you and others have done with this paper.
>> I have a few questions I'd like to ask if you wouldn't mind.
>>
>> #1, if we changed the non-bogus Host header to be the real host, do you
>> believe that would have any substantial negative impact?
>> #2 Is there anything else that is in the handshake proposal that is
>> perhaps HTTP compliant by the letter but not the spirit? (Other than CONNECT
>> vs UPGRADE -- I think you've made that case.)
>>
>> I personally don't care strongly enough about the above to call them a
>> requirement, but a number of people on this list have raised the HTTP compat
>> issue so I would like to better understand what that would imply with the
>> proposal this paper suggests the group move forward with.
>
> The change of the CONNECT URI to the known host "websocket.invalid" makes a
> difference, because a server can dispatch the known "websocket.invalid" host
> to a websocket handler. (The earlier scrambling of the URI was unworkable.)

This change is already incorporated in the current version of
draft-abarth-websocket-handshake.

> In other words, there's a difference between a well-known
> "websocket.invalid" host and a bogus host. A truly bogus host would be a
> problem (and wouldn't be HTTP in any meaningful way).
>
> That's from the end-server perspective. I don't know about proxies, although
> I'd think a websocket-aware proxy could unpack the embedded URL and forward
> based on it.

Great.  I'm glad it works for you.

Adam