I was trying out R2 for Discourse compatibility, and it appears, that other than missing the necessary x-amz-acl (which I believe is already a priority for you to enable), it appears that R2 is ignoring the content encoding setting.
Examples:
https://pub-06c6437075be4b2c8d3405b133585da9.r2.dev/assets/activate-account-1ec10d89bce01387a7dec2a6b155cd3fe7bcc9258c065a79bf6a95fd232778f2.gz.js was uploaded with a gzip content encoding but there is no such header in the response.
No, Cloudflare is not ignoring content-encoding.
Yes, R2 will gzip it:
% svo https://pub-06c6437075be4b2c8d3405b133585da9.r2.dev/assets/activate-account-1ec10d89bce01387a7dec2a6b155cd3fe7bcc9258c065a79bf6a95fd232778f2.gz.js --compressed 2>&1 | grep "< "
< HTTP/2 200
< date: Wed, 12 Oct 2022 03:44:06 GMT
< content-type: application/javascript
< cache-control: max-age=31556952, public, immutable
< etag: W/"60be3aa6f88631e2073aa83dfe78d420"
< last-modified: Mon, 10 Oct 2022 23:24:10 GMT
< vary: Accept-Encoding
< server: cloudflare
< cf-ray: 758cd5c678f37ea5-LAX
< content-encoding: gzip
Notably, R2 performs transparent decompression in a similar manner to Google Cloud Storage.
Depending on a variation of your request headers (i.e what encodings you accept) or how the object was stored (i.e if it has cache-control: no-transform), the object stored gzip’d in R2 might be decompressed on-the-fly as it’s returned to you.
This could explain why you’re not seeing it on your client.