websocket
websocket copied to clipboard
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 https://github.com/nhooyr/websocket/issues/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 https://github.com/nhooyr/websocket/pull/258#issue-696336768
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.