Re: [hybi] Shipping WebSockets

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.

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: hybi-bounces@ietf.org [hybi-bounces@ietf.org] on behalf of Greg Wilkins [gregw@webtide.com]
> Sent: Wednesday, December 15, 2010 09:03
> To: John Tamplin
> Cc: hybi@ietf.org HTTP
> Subject: Re: [hybi] Shipping WebSockets
> 
> On 15 December 2010 17:44, John Tamplin <jat@google.com> wrote:
> > On Wed, Dec 15, 2010 at 3:39 AM, Greg Wilkins <gregw@webtide.com> 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
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

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