#GZIPed responses from my origin are being decompressed with `Content-Type: application/octet-stream`

4 messages · Page 1 of 1 (latest)

mystic river
#

I am serving my responses from my origin compressed with gzip and content-encoding: gzip and content-type: application/octet-stream headers. When I request from this server the response I get back is not gzipped even though the accept-encoding header allows gzip. However if I set the content-type header to something like application/wasm then the response stays as gzip and is not decompressed. How can I keep a content type of application/octet-stream while also not having my responses being decompressed?

#

I'm guessing it has something to do with not being on this list https://developers.cloudflare.com/speed/optimization/content/brotli/content-compression/#compression-between-cloudflare-and-website-visitors
But why would that result in the response being decompressed, I would have thought the supported list would only being for compressing responses not already compressed at the origin.

Cloudflare compresses content in two ways: between Cloudflare and your website visitors and between Cloudflare and your origin server.

#

And I'd like to avoid the work around of setting a cache-control: no-transform as from what I understand this means compressed content would still be sent to users that can't accept it

kindred swan