'Sec-WebSocket-Accept' header is missing

[PS]

One of my users reports following in Chrome:

WebSocket connection to 'ws://bcs.domain.com' failed: Error during WebSocket handshake: 'Sec-WebSocket-Accept' header is missing

Any thoughts as why would someone see this?

[Simone Bordet]

Hi,

Using Chrome 1 ?

--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

[PS]

chrome Version 27.0.1453.110 m (latest)

[PS]

I can see that 101 Switching Protocols request, results in Sec-WebSocket-Accept header missing on my client's PC. It works fine for me here and on hundreds other computers, I can actually see this header in response in FireBug, so I am assuming it is localized issue for this particular person.

The handshake message returns with "false" and handshake response message looks a little bit weird, it looks like message within message.

message.advice

message.action = "handshake"

message.failure

message.failure.message

message.failure.message.advice

message.failure.message.channel

Even if there is some other issue why that header is missing, shouldn't cometd client in such cases gracefully fall back to long-polling?

[PS]

Also, client seems to go into re-hadshake loop, as advice is "retry" (with interval 0). I do not think that handshake failure should result into retry advice.

[Simone Bordet]

Hi,

CometD must retry on failed handshakes.

Do you have logs that can help out understanding what's going on ?

[PS]

If handshake fails with such error (or handshake was denied by application) it definitely should not retry to handshake again as it only results in endless loop of handshake attempts, i.e. resembling DDoS attack.

Clients report following issues:

Error 1: "WebSocket connection to 'ws://bcs.domain.com' failed: Error during WebSocket handshake: 'Sec-WebSocket-Accept' header is missing

Seen this error by remotely connecting to the client PC. Every browser resulted in it. While at the same time my connection in same browsers (version of those browsers) was fine. Can some proxy in this particular clients internet connection cause this problems? (it was happening on multiple PCs at their household).I am attaching 3 images related to this error: regular headers, headers when it fails and failed hadshake message object/.

Error 2: "WebSocket connection to 'ws://bcs.domain.com/bcs' failed: Unexpected response code: 400"

Do not know what to think about this one (temporary service server issue? temp server issue along the route? blocked/no allowed protocol on some proxy server?)

In jetty log I can see errors related to websockets only when message is too long and

2013-06-16 18:27:12.189:WARN:oejw.WebSocketFactory:Unsupported websocket client version specification <Unspecified, likely a pre-draft version of websocket>, configured minVersion [13], reported supported versions [13]

I am not 100 % sure if users are gracefully redirected to long-polling and this last error is transparent to them or not at this time. (could not reproduce error myself).

[Simone Bordet]

Hi,

On Mon, Jun 17, 2013 at 8:41 PM, PS <peter...@gmail.com> wrote:
> If handshake fails with such error (or handshake was denied by application)
> it definitely should not retry to handshake again as it only results in
> endless loop of handshake attempts, i.e. resembling DDoS attack.

If the websocket handshake fails, CometD falls back to long-polling,
and retries.

> Clients report following issues:
> Error 1: "WebSocket connection to 'ws://bcs.domain.com' failed: Error during
> WebSocket handshake: 'Sec-WebSocket-Accept' header is missing
> Seen this error by remotely connecting to the client PC. Every browser
> resulted in it. While at the same time my connection in same browsers
> (version of those browsers) was fine. Can some proxy in this particular
> clients internet connection cause this problems?

Likely.

> (it was happening on
> multiple PCs at their household).I am attaching 3 images related to this
> error: regular headers, headers when it fails and failed hadshake message
> object/.
>
> Error 2: "WebSocket connection to 'ws://bcs.domain.com/bcs' failed:
> Unexpected response code: 400"
> Do not know what to think about this one (temporary service server issue?
> temp server issue along the route? blocked/no allowed protocol on some proxy
> server?)

I think this is due to CometD misconfiguration of WebSocket on server side.

> In jetty log I can see errors related to websockets only when message is too
> long and
> 2013-06-16 18:27:12.189:WARN:oejw.WebSocketFactory:Unsupported websocket
> client version specification <Unspecified, likely a pre-draft version of
> websocket>, configured minVersion [13], reported supported versions [13]
> I am not 100 % sure if users are gracefully redirected to long-polling and
> this last error is transparent to them or not at this time. (could not
> reproduce error myself).

The WebSocket version is unspecified, so it means they are probably
using an old Safari browser.
No solution for this apart upgrade to decent modern browsers.

I have added two tests that remove the Sec-WebSocket-Accept header,
and both the Java client and the JavaScript client behave correctly,
falling back to long polling.

[PS]

My client side app is looking for message.ext.error when handshake fails (that is app level handshake denied) and because .ext doe snot exist in message object when protocol level failure occurs, javascript execution failed. Now after fixing it it looks like cometd is properly falling back to long-polling when protocol level failure happens.

Thank you for taking time investigating and good thinking on creating additional negative tests to the test suite.

[PS]

My client reports that Error 2 placed here is not handled correctly and cometd does not fall back to long-polling. could you please add test that will return "400" error?

[PS]

I poked around some more, using Safari 5.1.7:

WebSocket Upgrade attempts to fall back to long-polling, but result is error. See attached images of the failed websocket and long-polling handshake message objects. The error console prints "Unexpected response code: 400". Cometd then falls back all the way to callback-polling.

Simone, what are your thoughts on this? It server log this generates only the warning

2013-06-19 14:01:33.050:WARN:oejw.WebSocketFactory:Unsupported websocket client version specification <Unspecified, likely a pre-draft version of websocket>, configured minVersion [13], reported supported versions [13]

but I can not find anything in server logs which would indicate the "400 error"

[Simone Bordet]

Hi,

On Wed, Jun 19, 2013 at 11:05 PM, PS <peter...@gmail.com> wrote:
> I poked around some more, using Safari 5.1.7:

So, Safari 5 is utterly broken with respect to WebSocket.

I strongly recommend you disable WebSocket if it's Safari 5.

A test for a HTTP response of 400 already exist in the test suite, and
passes cleanly.

[PS]

A small question about fall back that is slightly related to this topic.

I have client with personal Watchguard firewall, and he can see some traffic denied with "Deny: HTTP Invalid Request-Line Format", I am just assuming it is the websocket upgrade call response that is denied.

If upgrade to websocket call never receives response from server, will client timeout and then fallback to long-polling?

[Simone Bordet]

Hi,

It should, yes.