Error during WebSocket handshake: 'Sec-WebSocket-Extensions' header value is rejected in Chrome browser (Version 66)

[Yi Wang]

Hi, 

Has anyone seen following error in Chrome browser (Version 66.0.3359.139 (Official Build) (64-bit)) when using cometd 3.1.4? I am using the cometd-demo (shipped in cometd 3.1.4) for the test.

WebSocket connection to 'ws://localhost:9081/notification/cometd' failed: Error during WebSocket handshake: 'Sec-WebSocket-Extensions' header value is rejected by the parser: permessage-deflate; client_max_window_bits=

Any advice how to solve above error and get it working in Chrome?

Many thanks for your help.

[Joakim Erdfelt]

Can you capture the request / response headers?

[Yi Wang]

Hi Joakim, thanks for your response. Here are the headers of the request and response. I use IBM Liberty server, not sure whether it makes things differently.

General:

1. Request URL:
   ws://localhost:9081/notification/cometd
2. Request Method:
   GET
3. Status Code:
   101 Switching Protocols

Request headers:

1. Accept-Encoding:
   gzip, deflate, br
2. Accept-Language:
   en-US,en;q=0.9
3. Cache-Control:
   no-cache
4. Connection:
   Upgrade
5. Host:
   localhost:9081
6. Origin:
   http://localhost:9081
7. Pragma:
   no-cache
8. Sec-WebSocket-Extensions:
   permessage-deflate; client_max_window_bits
9. Sec-WebSocket-Key:
   OrRNPW1Me2S//P6/zwkBOQ==
10. Sec-WebSocket-Version:
    13
11. Upgrade:
    websocket
12. User-Agent:
    Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36

Response headers:

1. Cache-Control:
   no-cache="set-cookie, set-cookie2"
2. Connection:
   Upgrade
3. Content-Language:
   en-US
4. Content-Length:
   0
5. Date:
   Mon, 18 Jun 2018 23:32:33 GMT
6. Expires:
   Thu, 01 Dec 1994 16:00:00 GMT
7. Sec-WebSocket-Accept:
   UFkh+LXe8DiCf1eyRwST7V8jLmM=
8. Sec-WebSocket-Extensions:
   permessage-deflate; client_max_window_bits=
9. Set-Cookie:
   JSESSIONID=0000xyiXS4LqQgDJySLQqt_5O39:d013abf9-4469-416a-b288-2e9be173f249; Path=/; HttpOnly
10. Upgrade:
    websocket
11. X-Powered-By:
    Servlet/3.1

[Joakim Erdfelt]

Your server is not negotiating the permessage-deflate extension properly.

The request (from Chrome 66 running on Windows)...

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

which means there's no client_max_window_bits declared, so use maximum.

The response ...

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits=

is bad due to the missing parameter value on client_max_window_bits.

The extension negotiation for client_max_window_bits should either not be present, or have the same value as the offered client_max_window_bits.

See: https://tools.ietf.org/html/rfc7692

Note: Jetty's WebSocket server does not offer or negotiate client_max_window_bits or server_max_window_bits as Java's deflate implementation does not allow you to set/configure the window bits.

- Joakim

[Yi Wang]

Thanks Joakim for your reply. I am pretty new with Cometd 3.1.4, specifically in the websocket part. Do you know what part of the code sets these response headers? In Cometd or the app server (IBM liberty in my case)? If it is inside cometd code, do you know the class name? 

I run the same test in IE, IE seems no complains. Not sure whether anything I can do in the JS side so that chrome can behavior similarly as IE?