unsupported permessage-deflate parameter: "client_max_window_bits=15" from client

If a websocket server reply with extension permessage-deflate; client_max_window_bits=15 an error happens:

unsupported permessage-deflate parameter: "client_max_window_bits=15"

at
https://github.com/nhooyr/websocket/blob/bd07a64be6809ef46b76fff5ef7263ef7641980f/dial.go#L268-L300

Since we don't include it in the handshake request whatever server you're trying to use isn't implementing the RFC correctly.

See https://datatracker.ietf.org/doc/html/rfc7692

   If a received extension negotiation offer doesn't have the
   "client_max_window_bits" extension parameter, the corresponding
   extension negotiation response to the offer MUST NOT include the
   "client_max_window_bits" extension parameter.

The library is correct to error on it.

I did include the client_max_window_bits parameter because that's what the Chrome browser does. I fixed it in my fork.

related #351

The situation is different from #351.

There the server is hinting us on its window size but that doesn't matter to use as we always use the largest window size. See #258 (comment)

Here if you include client_max_window_bits you're telling the server it can reply with client_max_window_bits with a value less than 15. But we don't support that as we cannot adjust the window size to be less than 2**15.

   If a received extension negotiation offer has the
   "client_max_window_bits" extension parameter, the server MAY include
   the "client_max_window_bits" extension parameter in the corresponding
   extension negotiation response to the offer.  If the
   "client_max_window_bits" extension parameter in a received extension
   negotiation offer has a value, the server may either ignore this
   value or use this value to avoid allocating an unnecessarily big LZ77
   sliding window by including the "client_max_window_bits" extension
   parameter in the corresponding extension negotiation response to the
   offer with a value equal to or smaller than the received value.

If you know a way to adjust the window size dynamically with the standard library deflate package I'd be happy to add support and then we can support these extensions parameters fully.

In my case the server always reply with client_max_window_bits=15, I made websocket accept that

switch p {
  case "client_no_context_takeover":
	  copts.clientNoContextTakeover = true
	  continue
  case "server_no_context_takeover":
	  copts.serverNoContextTakeover = true
	  continue
  case "client_max_window_bits=15":
	  continue
}

But you just said

I did include the client_max_window_bits parameter because that's what the Chrome browser does. I fixed it in my fork.

If you didn't include it and the server is always replying then the server is broken. It's violating the RFC.

I meant the server replies with client_max_window_bits=15 when the client sends client_max_window_bits, so it won't break this library

Probably most servers do that

Ok fair enough I'll add a bypass here too.

@nhooyr

Hi @nhooyr

Have you considered using https://github.com/klauspost/compress/blob/v1.18.0/flate/deflate.go#L947 ?

It seems like it supports custom window sizes.

Navigation Menu

Repository navigation

unsupported permessage-deflate parameter: "client_max_window_bits=15" from client #443

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

unsupported permessage-deflate parameter: "client_max_window_bits=15" from client #443

Description

Activity

nhooyr commented on Apr 9, 2024

HMaker commented on Apr 9, 2024

HMaker commented on Apr 9, 2024

nhooyr commented on Apr 9, 2024

HMaker commented on Apr 9, 2024

nhooyr commented on Apr 9, 2024

HMaker commented on Apr 9, 2024

nhooyr commented on Apr 9, 2024

hexdigest commented on Aug 12, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions