Re: [hybi] WebSocket, TLS and intermediaries

[Roberto Peon <[e-mail]>]

 +1
-=R

On Wed, Jul 21, 2010 at 5:11 PM, Willy Tarreau <[e-mail]> wrote:

> On Thu, Jul 22, 2010 at 09:55:50AM +1000, Greg Wilkins wrote:
> > On 22 July 2010 09:42, Mike Belshe <[e-mail]> wrote:
> >
> > > On the TLS issue, we're going in circles.  Both sides are correct on
> the
> > > facts about the pros and cons of TLS (more or less).  I don't think the
> spec
> > > should require TLS.  But, would it be possible to define alternate
> > > handshakes based on whether TLS is used?
> > >
> > > If we use the currently defined handshake, TLS will be at a performance
> > > disadvantage to insecure WebSockets, because TLS will require more
> > > round-trips.
> > >
> > > Could we define, as part of the WebSocket protocol, that when WebSocket
> is
> > > negotiated over TLS it uses the TLS/NPN extension to effectively fold
> the
> > > WebSocket Upgrade handshake into the TLS handshake?  This removes a
> round
> > > trip from the WebSocket startup time.  The next-protocol-negotiation
> > > extension is defined here:
> > > http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00
> > >
> >
> > +1
> >
> > there has been on opinion expressed that we can only ever have 1
> websocket
> > handshake.  Thus because we are starting with port 80, the handshake is
> > currently some mutant child of HTTP that must be sent even if another
> port
> > is used and no HTTP is involved.
> >
> > This approach is  stuck trying to fixate on the exact syntax of the
> > handshake, literally down to counting spaces!
> >
> > Instead we need to establish the semantic context in which a websocket
> > connection can be established, and then allow multiple ways to establish
> > that context.   HTTP upgrade is one such way, TLS/NPN is another.
>
> +1 !
>
> Regards,
> Willy
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>