Origin does not receive Accept-Encoding

When fastly is configured " Use Brotli compression when available" (via Web interface - not custom VCL) Accept-Encoding does not reach the origin
But when “Use gzip compression only” config is set origin receives “Accept-Encoding: gzip” .

Default compression policy is enabled in both cases. But urls don’t have file extensions (text/html is served on url like https://example.com/path)

Fastly responds with X-Cache MISS, MISS - this is fine
But in case of “Use Brotli” response is obviously not compressed!

This behavior is at least inconsistent.
And it is not clear at all why Fastly does not keep “br” in Accept-Encoding

What is exactly wrong here?

I did extra debugging
When Use Brotli compression when available
VCL contains

if (req.http.Fastly-Orig-Accept-Encoding) {
    if (req.http.Fastly-Orig-Accept-Encoding ~ "\bbr\b") {
      set req.http.Accept-Encoding = "br";

fastly-orig-accept-encoding value is br
Fastly logs also show request_accept_encoding : br
Accept-Encoding does not come to origin

In case of Use gzip compression only

fastly-orig-accept-encoding value is gzip
Accept-Encoding Value: gzip

and a similar “if” block is missing

So why accept-encoding is missing in this case? I believe it is a bug.

Hi @rymsha,

That behaviour is very odd. I think we probably need to look at your service, could you email support@fastly.com and include your service ID and the version number of the service that is exhibiting this behaviour?

Apparently it happens only when WAF is enabled. So it is still an issue for us, we just narrowed the problem.
I repeat - gzip is not affected. only br

Is that the legacy Fastly WAF you’re using or next gen cloud WAF?