Re: [hybi] WebSocket, TLS and intermediaries

[Patrick McManus <[e-mail]>]

On Wed, 2010-07-21 at 22:09 -0700, Roberto Peon wrote:
>  +1

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

>         > 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 !


+1 for me as well.

More specifically, I think the web sockets specification should define
the unique web socket protocol (shocking!). That protocol should NOT
bear a sometimes-it-is-convenient-to-look-like-http-without-being-http
look. Not being HTTP, that is just asking for confusion. It should of
course do the security checking that the list has been discussing.

If clients and servers would like to use that protocol directly - that
would be terrific and I doubt anyone here would be upset about that.

If clients and servers need to tunnel over HTTP in order to use
websockets, then use one of the established mechanisms for doing that
(e.g. Upgrade). It is fine to include a section in the websocket
specification on "upgrading to websockets over http" with implementation
advice, but that should be its scope. 

The notion of the WG endorsing a specification that sends
non-compliant-HTTP to HTTP ports is non sensical for the IETF. My
personal interpretation of the mailing list archive says that their is
consensus on that. I would hope that browser vendors would choose not to
ship such a scheme in anything except an experimental fashion.

It does cost 1 RTT to do an HTTP upgrade safely before allowing any
websocket or user supplied data to hit the wire. That is not a property
of websockets - that is a property of HTTP. Consider it the cost of
doing business if you would like to piggyback on http's port. honestly,
for the value of getting access to port 80 real estate - its a pretty
cheap price! If you use a different port then it can be avoided - the
cost and benefit are clearly defined.

personally, I'm not all that concerned about the 1st event latency for
websocket use cases. If they are no-wait instantaneous
events/status-dumps then they are well suited to http instead of
websockets. The latency of each additional event while the page is in
operation is much more important and is the websocket sweet spot. I
think this point of view is even more defensible if we include
multiplexing from day 1 - that will severely reduce the number of
handshakes.