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

["Shelby Moore" <[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

Agreed, but won't there be cases where WS/HTTP will refuse to work and
thus you must have Comet/BOSH to fall back on as they always work.  Do not
conflate timeouts with unrecoverable failure, where for example a proxy
still won't allow some data to pass though in WS/HTTP.

WS/port+tunnel is another option that uses only 1 connection and it has
advantage that the hard failure (not the recoverable timeouts and network
instability) will occur at the handshake and only once per
client+server(+DCHP lease) pair.