https://kotlinlang.org logo
Join Slack
Powered by
Hello, I have a problem with deflater, I use ktor ...
# ktor
a
Hello, I have a problem with deflater, I use ktor CIO http client on server and ktor JS http client on client, I also use a websockets, how can I gzip messages?
b
Simple, just install ktor gzip plugin (search on ktor.io)
a
@Big Chungus I'm not sure, I found that it using jvm implementation on server side, but client doesn't handle it, isn't it?
b
There's a client gzip plugin too
a
not for JS 🙂
b
(i think)
a
It's applicable for jvm http engine
b
Doesn't the browser handle gzip then? I've used ktor with gzip before and hadn't encountered any problems. Don't think I've done anything special.
Have you tried installing gzip plugin on the server and trying to talk to it from webapp?
Should just work
a
yep, it should, but there is only WebSocketDeflateExtension for websocket, that deflate and inflate only on JVM, so I have to gzip my bytearray manually and I can't ungzip on kotlin client JS 🙂
b
Ktor client is built on top of fetch api. Have you actually tried fetching gziped data? What's the crash message?
a
Are we talking about websockets?
b
Yes, any network activity from the browser
a
Gzip plugin it is under Compression plugin? https://ktor.io/docs/compression.html
b
I think so yes, but that's not what I've asked 😀
a
Then my websocket messages doesn't use gzip. I see the info in network tab on chrome, so it means that gzip doesn't work 🙂
b
Right, so your problem is on the server, not the client
i.e. server doesn't gzip ws messages. Might be something extra that needs configuring for ws rather than regular http stuff on the server
Looks like http and ws don't share lots of configs
a
yep, as far as I know we should use WebSocketDeflateExtension, but it sends a compressed data (bytearray) to client, so I couldn't uncompress it, because compress/uncompress is implemented for jvm only on top of java
b
Do you have maven coordinate for that plugin dependency?
a
WebSocketDeflateExtension?
b
Yes
a
io.ktorktor websockets jvm2.1.1 io.ktor.websocket.WebSocketDeflateExtension
b
Have you installed it client-side too?
a
I can't because client is JS
b
It does have a js artefact as well
As you can see in the picture above
a
nope %)
ktor-websockets - yes
ktor-websockets-jvm - jvm only
b
Or you mean it's pure js, not kotlin js
a
kotlin js
b
Are you new with kmp?
a
no
b
Basically -jvm is just a target artefact flavour for the same lib. So for js it's the same coordinate with -js suffix
Or if you're using gradle, you can ommit all target suffixes from kmp dependencies and it will figure out the right ones
i.e. try adding ktot-websockets to your jvm dependencies without -jvm suffix
a
I already did that
b
On the client?
a
yep
my websockets already works, but I can't import WebSocketDeflateExtension cause it doesn't exists for js
b
So you do have the websocket dependency. Are you saying that WebsocketDeflateExtension is not inside js flavour?
a
yes
b
Ahh, got it! Yeah, we've been walking in circles all along then 😀 Apologies
a
ok 🙂
b
Looks like you'll need to implement it yourself via https://ktor.io/docs/websocket-extensions-api.html#installing-extension then
a
yeah, but I can't
b
You could hook into some npm gzip package to avoid fully reinventing the wheel
a
yep, this is a very complex way for achieving that, I hope that there is an another way, cause add npm package it is a really headache
b
I would not count on it. Ktor client for js has always been kind of an afterthought when compared with native and jvm versions
I don't, I'm just an outside observer 😀
a
oh yeah, ktor js has a lot of bugs
b
Not just that. Awful feature parity as well
a
;/
r
Is there a way to see/debug gzipped websocket messages in Firefox (or other browser)?
a
you can see messages that were sent, so gzip message should consist of some unreadable data %)
r
I have enabled the extension in my ktor server app, but I don't see any difference in the messages being sent.
a
yep, it doesn't work
what extension do you use?
r
a
yep, I can't see any difference too
r
I see some difference in the server response headers. Without the extension they look like this:
Copy code
HTTP/1.1 101 Switching Protocols
upgrade: websocket
connection: Upgrade
sec-websocket-accept: E4Mbsb3aDE7adgYjzvu8AlK5+oU=
when the extension is enabled there is one additional header:
Copy code
sec-websocket-extensions: permessage-deflate
a
I can't check, but I think that this extension works only for jvm clients (like microservices transport)
it setups through this header
r
I'm not so sure
I've checked http traffic with wireshark
It's different
Without server extension the data is sent as plain text
With the extension it looks compressed
Without the extension
With the extension
What's interesting the data from the client looks compressed in both cases.
And it seems to be completely transparent in the browser.
a
What client do you use?
r
A custom client based on browser websocket API
a
Oh, i see, seems no deflate for binary format, i use binary serialization instead of json
c
Usually when you configure deflate in Apache Web Server you indicate which mimetypes are supported. I image you can do the same with the plugin. It wouldn't gain that much for most binary formats.
77 Views
Open in Slack
PreviousNext
Powered by