The Accept-Encoding header send to the origin server is "gzip" only not include "br"


The Accept-Encoding header sent by my browser is “gzip, deflate, br”. However, my origin server only receives the Accept-Encoding header as “gzip”. All the articles mention that the origin server should receive the request header as “br, gzip”.

For incoming requests, the value of this header will always be set to accept-encoding: br, gzip . If the client set a different value, such as accept-encding: deflate , it will be overwritten and the original value will be available in .

I have already enabled the Brotli switch in the Speed > Optimization > Content Optimization tab.

And I performed the following tests:
Whether I used the command curl https://mysite -I -H "Accept-Encoding: gzip" or curl https://mysite -I -H "Accept-Encoding: br", I checked the Nginx logs on my origin server and found that the Accept-Encoding header sent by Cloudflare only contained “gzip”. And the response after my curl command is “br”.

However, if I disable the Brotli switch, I still receive only “gzip” in the Accept-Encoding header, and the response after the curl command is also “gzip”.

The above tests indicate that the Brotli switch is effective, but why am I only receiving “gzip” on my origin server? How can I receive “br”?

Sincerely yours

1 Like

ref issue - Accept Brotli when taking data from the origin
It is a similar situation to the issue mentioned above, but I think the issue has not been resolved.

Yeah, that ticket was closed to soon, and somehow an answer with no solution has been chosen as the solution, with no possibility to object or anything.

However, as of a week or two ago, our origin started to receive both gzip and br. Maybe they roll it out gradually or something.

Enable Brotli:
client(browser) send request with “Accept-Encoding: br”
→ Cloudflare send request with “Accept-Encoding: gzip” // here is unexpected
→ Origin server receive request with “Accept-Encoding: gzip”
← Origin server return response with “content-encoding: gzip”
← Cloudflare return response with “content-encoding: br” // Enabling the Brotli is effective.

Disable Brotli:
client(browser) send request with “Accept-Encoding: gzip”
→ Cloudflare send request with “Accept-Encoding: gzip”
→ Origin server receive request with “Accept-Encoding: gzip”
← Origin server return response with “content-encoding: gzip”
← Cloudflare return response with “content-encoding: gzip” // Disabling the Brotli is effective.

The problem still exists. Can anyone help fix this issue? Or assist in submitting a bug report?

I am seeing this behavior as well. Oddly enough, our origin had been getting "Accept-Encoding: br, gzip” for a period of time, but Cloudflare dropped br on 10/27.

I had opened a support ticket (#2993959) on 10/20 because I was not seeing evidence that the compression passthrough was happening. My impression was that Cloudflare was recompressing my origin’s br11 content with br4 on the fly.

On 11/1 I updated the original support ticket to ask about why br was dropped from the Accept-Encoding header to my origin. I haven’t gotten a response on the ticket yet, but I’ll try to update here when I do.

My suspicion is that this person had it right with their community comment elsewhere: End-to-end Brotli? - #5 by i40west. Things with Cloudflare’s brotli from origin don’t seem to be entirely working quite yet.

The Cloudflare team confirmed that the feature was disabled. Let’s hope they are able to resolve the issue.

1 Like

I do wonder if disabling it is related to Cloudflare sending brotli encoded content when requesting gzip encoding. It seems to line up with when br was removed from requests to your origin @ty15.

The following has recently been added to the docs:

Brotli support is scheduled to be gradually rolled out beginning February 1st, 2024. Until then, only Gzip compression is supported between Cloudflare and your origin.


1 Like