If you use http handler for your service, which is the default setting for [http_service] fly.toml configuration, fly-proxy compresses HTTP responses sent by your app.
Brotli had been the preferred compression algorithm used by the proxy until now, as it provides good compression rate and fast compression/decompression speed.
Recently, Chrome added support for ZSTD compression algorithm (Chrome Platform Status), the other major browsers are expected to follow. fly-proxy now supports it too. Compared to Brotli, ZSTD is slightly faster to compress on the server side and much faster to decompress on the client side.
You don’t need to do anything to enable it for your app. If the client indicates support for ZSTD via Accept-Encoding HTTP header, the proxy will use it as the new preferred compression algorithm.
If you control the client you can just omit zstd and br from Accept-Encoding.
If you don’t control the client, you can gzip compress the responses in your app. The proxy won’t touch the response if it’s already compressed by an app.
This default caused me some minor inconveniences. Firefox appears to support this now, but the “Response” tab in the DevTools doesn’t decode it correctly so you get a garbled result:
This comes down to the version of curl/libcurl you have. I have two computers here: the one with Ubuntu 20.04 does what you showed, but the one with 22.04 is happy. The command I tried:
The key here is the --compressed flag which Firefox’s save as curl gives you. It instructs curl to try to decompress the response to show the final content. If curl doesn’t understand the compression then it’ll barf as you showed.
The one on Ubuntu 20.04 does not have zstd while the one on 22.04 above does (last line).
On 20.04 it’s Curl 7.68.0 (same version for libcurl). zstd support was introduced in curl/libcurl 7.70.
As for Firefox - zstd support was supposedly added in Firefox 126, the gibberish in the response payload might be a bug on their side or it could be “by design” depending on whether the idea is for “response payload” to show the verbatim binary blob that was received (in your case though, since it’s ostensibly trying to decode json, I would expect it not to choke on the blob, but decompress and json-decode it!).
@pmbanugo it was mentioned that compressed responses from the server aren’t modified, so you’ll have to change your server to send uncompressed responses.