Hi @sheerun, it looks like this is an artifact of our implementation. While Cloudflare supports brotli and gzip to eyeballs, we only support gzip between CF and origins (see https://support.cloudflare.com/hc/en-us/articles/200168086-Does-Cloudflare-compress-resources-). The Workers runtime lives on the origin side of this divide, so it’s not able to perform content negotiation directly with the eyeball, but rather with a proxy.
@harris I think this fact (that requests forwarded to origin have Accept-Encoding header changed) should not affect Cloudflare Worker, precisely because it’s working at edge, not origin. I cannot control this header because it’s set by browser. I also cannot change header name because it’s not accessible in any way in Cloudflare Worker.
I’d ask Cloudflare team to consider this a bug rather than implementation detail. If you want to change Accept-Encoding header (and it makes sense for your use case), please consider doing so after worker executes its code, not before, as to allow copying or renaming this header in worker code (or at least accessing it).