Hi Any reason why the `Sec WebSocket Extensions` is always <https github com square okhttp commit b17d8f1c39ce25e968d66b9d3d65d60a1a6683d6 diff ec54159da4c0de7e6c71758172aecfa27b94956e76d3ddba7d6a507a4f893962R162|applied> I don t see any option to remove it this is causing an issue in <https youtrack jetbrains com issue KTOR 6266 OkHttp Remove the default WebSocket extension header Sec WebSocket Extensions|Ktor> Websocket client It s also unnecessary to do any compression if the Websocket server is already doing custom compression and sending binary Frames only

is always applied (I don’t see any option to remove it), this is causing an issue in Ktor Websocket client. It’s also unnecessary to do any compression if the Websocket server is already doing custom compression and sending binary Frames only.

10/26/2023, 12:06 PM

This is advertising support, not applying the behavior. If your server is doing compression in binary frames then it shouldn't enable compression when talking to the client. Servers are free to reject the use of any advertised extension for any reason. I don't see any bug in ktor there. You're just seeing the default OkHttp behavior.

It sounds more like a bug / misconfiguration of the server where it unconditionally accepts the compression extension as suggested by the client. Since your application does not want that, it should be configured on the server to not enable it regardless of whether the client supports it or not.

thank you color 1

➕ 1

yschimke

10/26/2023, 12:21 PM

For consistency, we do allow setting the encoding header for normal http, disabling gzip. So there is an argument to allow. But agree it's an enhancement.

10/26/2023, 12:43 PM

So maybe allow specifying the header in the request explicitly with either identity or any of the known extensions we support, failing on unknown values?

jessewilson

10/27/2023, 3:37 AM

I don’t think we can do arbitrary user compression in web sockets

Advertising support for the standard compression mechanisms is pretty boring and gives the server all the power

10/27/2023, 3:38 AM

I think they're saying it's application-level compression, like sending a PNG not a BMP, and the server is needlessly accepting the WS compression and wasting CPU

jessewilson

10/27/2023, 3:39 AM

Gotcha

I believe our current policy is hardcoded to compress everything larger than 1 KiB

We could do better in how flexible our configuration is

10/27/2023, 3:40 AM

That's if compression is enabled. They want an option to disable advertising the extension in the initial request to the server. Similar to specifying

Accept-Encoding: identity

on a normal request to overwrite an implicit

Accept-Encoding: gzip

that is advertised by default

☝️ 1