Re: [hybi] Shipping WebSockets

[Mark Nottingham <[e-mail]>]

On 16/12/2010, at 12:20 PM, Maciej Stachowiak wrote:

> 
> On Dec 15, 2010, at 4:59 PM, Mark Nottingham wrote:
> 
>> From an HTTP standpoint, this looks good to me, and it nicely demonstrates a point I've been trying to make repeatedly -- that we don't have to fall into the trap of a false choice between the 'old' upgrade proposal and the CONNECT proposal.
>> 
>> I'm very interested to hear the reactions of the CONNECT proponents.
> 
> - I don't think this proposal does anything to address the flaws found by Adam's study.

Can you be more specific, Maciej? 

If the hybi-specific handshake is sufficiently unlike an HTTP request/response pair, it should fail when there's an intercepting proxy interposed. 


> - In fact I don't think anything about this proposal meaningfully improves security relative to the current draft. Some of the changes may have good non-security motivations I see it as a waste of time to putter around the edges of the handshake until we have security figured out. Security issues currently make the protocol non-viable. I don't see the value in producing more drafts that are not safe to ship in product.

See above. Perhaps you haven't examined the proposal closely enough.


> - The summary claims that this handshake doesn't introduce a round trip, but it clearly does, since the hello frames are only exchanged after the handshake completes.

I don't see any indication that the client nor server needs to block before sending; only that a certain frame must be sent before any others, in each direction. That shouldn't add a round trip.


> (That's setting aside the obvious point that this internet-draft is not suitable for use as drop-in spec text, both due to being written as an old vs. new comparison and due to insufficient detail.)

As pointed out in the draft, this is a very typical change proposal. If you're going to reject proposals based on their formatting, we are indeed in for the long haul.

Regards,


> 
> For these reasons, I think the proposed draft is not a particularly useful direction.
> 
> Regards,
> Maciej
> 
> 
>> 
>> Regards,
>> 
>> 
>> On 16/12/2010, at 5:30 AM, Gabriel Montenegro wrote:
>> 
>>> FYI, we have submitted a draft that's essentially the handshake that Greg proposed a while back.
>>> We'd like to use it as a basis for further iteration.
>>> 
>>> http://tools.ietf.org/html/draft-montenegro-hybi-upgrade-hello-handshake
>>> 
>>> Agree on base64.
>>> 
>>> Gabriel
>>> From: [e-mail] [[e-mail]] on behalf of Greg Wilkins [[e-mail]]
>>> Sent: Wednesday, December 15, 2010 09:03
>>> To: John Tamplin
>>> Cc: [e-mail] HTTP
>>> Subject: Re: [hybi] Shipping WebSockets
>>> 
>>> On 15 December 2010 17:44, John Tamplin <[e-mail]> wrote:
>>>> On Wed, Dec 15, 2010 at 3:39 AM, Greg Wilkins <[e-mail]> wrote:
>>>>> Does anybody object to wrapping the nonce/hash bytes sent after the
>>>>> handshake requests as HELLO frames?  This means that implementations
>>>>> only need to deal with 2 framing mechanisms not 3.
>>>> 
>>>> In the absence of information about the rest of the handshake, yes.
>>>> All else being equal, I would prefer they be included in headers.
>>> 
>>> Well I would not argue with them being headers either.
>>> 
>>> 
>>>> I don't understand what you mean about 2 framing mechanisms instead of 3 though.
>>> 
>>> The connection opens, you first have to parse HTTP.  You then have to
>>> parse 8 bytes.  You then parse websocket packets.
>>> 
>>> Sure that is trivial if you are writing a blocking implementation.
>>> But if you want to scale, you have to be asynchronous and you can't
>>> assume that all the 8 bytes will arrive at once.  So you have to have
>>> a little state machine to track the arrival of those bytes.  This is
>>> just needless complication and will be a source of errors.    If the
>>> bytes are framed as WS, then you can simply switch from the HTTP
>>> parser to the WS parser
>>> 
>>> Also, without any framing, then any 8 bytes sent (eg another HTTP
>>> request) will look like the random bytes.  This is not robust
>>> 
>>> 
>>> 
>>> 
>>>>> Does anybody object to simple hex encoding of nonces and hashes?
>>>> 
>>>> I wouldn't block it, but base64 seems better and sufficient.
>>> 
>>> sure b64 is good also.
>>> 
>>> 
>>> cheers
>>> _______________________________________________
>>> hybi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hybi
>>> 
>>> _______________________________________________
>>> hybi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hybi
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> _______________________________________________
>> hybi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hybi
> 

--
Mark Nottingham   http://www.mnot.net/