When making a request for server-rendered HTML or CSS in a Go app, I noticed that the response when served from *.fly.dev has Content-Encoding: gzip
Does fly have a layer that handles compression? Does it only do gzip, or can it handle brotli?
I am trying to understand what features I need to build into the app itself. I can’t find a clear answer in the documentation though.
These are not files from [[statics]], these are server-rendered files.
We handle compression automatically, unless explicitly disabled via a, currently, undocumented option.
We used to support brotli, but the rust library we used kept panicking. We left it out until this is resolved upstream.
Short answer: if you want to use brotli, you’ll need to implement it yourself. If you want gzip or deflate, that’s already handled by our proxy.
@jerome thank you, that is amazing.
Is this documented anywhere? Are there other benefits of the proxy that I can leave out?
For example, because you are handling this, I don’t need to set a Vary header. But I see you’re not setting it either.
It’s not documented at this time 
.
We try to keep requests and responses as-is as much as possible. Compression seemed like something we should do to prevent thousands of apps implementing their own.
Hmm, you might still want to set the Vary header here. We’re not caching anything, but if something upstream does, then it should vary by content-encoding.
FYI, if you’re considering promoting this to a supported feature, an example of how others do it: The folks at Cloudflare key off of Cache-Control: no-transform to disable features like gzip, image minification, etc (their docs).
(We found this out the hard way when their frontends were stripping our etags, a consequence of one of those rewriting features…)
Good call! I’ve added this to our internal issue tracker.