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

[HMaker]

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

[nhooyr]

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.

[HMaker]

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

[HMaker]

related #351

[nhooyr]

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.

[HMaker]

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
}

[nhooyr]

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.

[HMaker]

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

[nhooyr]

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

[hexdigest]

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.