Home/ Questions/Q 8259733
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T02:55:56+00:00

We’ve got a problem with Chrome 19 websockets. It is attempting to connect to

  • 0

We’ve got a problem with Chrome 19 websockets. It is attempting to connect to our server using the x-webkit-deflate-frame extension. However, I can’t work out how to indicate to that client that we don’t support that extension (or if it’s a Chrome 19 bug and is just ignoring the fact that we don’t support it?). I have seen this problem related in a few SO answers but I can’t see a consistent solution.

For example, if we receive the headers

Upgrade: websocket
Connection: Upgrade
Host: titantest:30100
Origin: http://titantest
Sec-WebSocket-Key: f+7h4rrKKqdRRdD7WwTZow==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: x-webkit-deflate-frame

What should we respond with?

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 3eazAhsFLXFWB1OjcYMtzP13yag=

and then appended to that I’ve tried various Sec-WebSocket-Extension varieties

Sec-WebSocket-Extension: '-'
Sec-WebSocket-Extension: -
Sec-WebSocket-Extension: 
<- blank: don't send a Sec-WebSocket-Extension header ->

I’ve also got a copy of the websocket protocol in front of me, so feel free to point out what I’ve missed/misread.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Section 9.1 of RFC 6455 deals with extension negotiation.

    A client proposes a list of extensions and the server chooses from those proposed which it wants to accept and indicates that choice using its return Sec-WebSocket-Extensions header. It can accept none by not including the extension header at all in the server handshake response.

    Is chrome 19 having a specific problem when you return no extension header?

    • 0