Re: [hybi] #4: handshake does not work properly with HTTP reverse proxy.

[Greg Wilkins <[e-mail]>]

On 15 August 2010 19:59, Shelby Moore <[e-mail]> wrote:
> Greg Wilkins wrote:
>> This is already an issue with cometd-2, now that we support websocket
>> as an optional transport.  When it is enabled, there is noticeable
>> additional establishing a comet web page (eg logging into a chat
>> room), while websocket hand shake is tried and fails, before the next
>> handshake is tried.
>
> Use the BOSH or Comet in parallel until WebSocket handshake is completed?


Using websocket in parallel would just increase the connection count
and complexity of applications as they try to deal with something that
is essentially a transport concern.

When a web page downloads, the browser will typically use 2-6 HTTP
connections to download all the content, css, images, script etc.   It
makes perfect sense to me that if the scripts then start a websocket
connection, then the browser should be able to take one of those 2-6
existing connections an try a websocket upgrade.  That is a single
round trip to check and establish websocket is supported.

Sure there are failure modes where a websocket connection is accepted,
but then does not actually work (or subsequently fails to work).  But
there are similar failure modes with BOSH/comet and implementations of
those protocols still need to implement timeouts etc to catch all
failures. Websocket is not a silver bullet that will suddenly make the
internet a truly error free reliable network.


For me, the attraction of websocket is mostly that it offers the
possibility of reducing the long term connection count per client from
2 to 1. That it promises some potential improvements in data density
and max latency is entirely secondary for me.

cheers