unsupported permessage-deflate parameter: "client_max_window_bits=15" from client about websocket HOT 8 OPEN

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.

from websocket.

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

from websocket.

related #351

from websocket.

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.

from websocket.

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
}

from websocket.

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.

from websocket.

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

from websocket.

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

from websocket.