Your solution doesn’t fix the problem. Adding per-account rules because a default setting works incorrectly is a workaround at best, and I can’t even apply it on one of my accounts. (I have undeleted the message above that I originally deleted to avoid distractions from the core problem.)
so no, it should not default to uncompressed, the lack of the Accept-Encoding request header will make Cloudflare start with “Zstd”, then “Brotli” and so on.
You are correct about this according to the RFC. But this is not how any website I can test behaves. They all return uncompressed responses when Accept-Encoding is not provided. Example on Cloudflare.
curl -v https://feedmail.org/
* Host feedmail.org:443 was resolved.
* IPv6: 2606:4700:3030::6815:1001, 2606:4700:3030::6815:2001, 2606:4700:3030::6815:3001, 2606:4700:3030::6815:4001, 2606:4700:3030::6815:5001, 2606:4700:3030::6815:6001, 2606:4700:3030::6815:7001
* IPv4: 104.21.16.1, 104.21.32.1, 104.21.48.1, 104.21.64.1, 104.21.80.1, 104.21.96.1, 104.21.112.1
* Trying [2606:4700:3030::6815:1001]:443...
* Immediate connect fail for 2606:4700:3030::6815:1001: Network is unreachable
* Trying [2606:4700:3030::6815:2001]:443...
* Immediate connect fail for 2606:4700:3030::6815:2001: Network is unreachable
* Trying [2606:4700:3030::6815:3001]:443...
* Immediate connect fail for 2606:4700:3030::6815:3001: Network is unreachable
* Trying [2606:4700:3030::6815:4001]:443...
* Immediate connect fail for 2606:4700:3030::6815:4001: Network is unreachable
* Trying [2606:4700:3030::6815:5001]:443...
* Immediate connect fail for 2606:4700:3030::6815:5001: Network is unreachable
* Trying [2606:4700:3030::6815:6001]:443...
* Immediate connect fail for 2606:4700:3030::6815:6001: Network is unreachable
* Trying [2606:4700:3030::6815:7001]:443...
* Immediate connect fail for 2606:4700:3030::6815:7001: Network is unreachable
* Trying 104.21.16.1:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /nix/store/2vjhfxc2vpval8v76v0hn1d2rpincpgd-nss-cacert-3.108/etc/ssl/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=feedmail.org
* start date: Feb 3 09:39:23 2025 GMT
* expire date: May 4 10:37:40 2025 GMT
* subjectAltName: host "feedmail.org" matched cert's "feedmail.org"
* issuer: C=US; O=Google Trust Services; CN=WE1
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
* Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Connected to feedmail.org (104.21.16.1) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://feedmail.org/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: feedmail.org]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.12.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: feedmail.org
> User-Agent: curl/8.12.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< date: Fri, 14 Mar 2025 13:17:48 GMT
< content-type: text/html;charset=UTF-8
< etag: W/"b5e0aaabfa55ce0052f4a76252be8548f11911f2"
< cache-control: max-age=60,stale-while-revalidate=600,stale-if-error=86400
< access-control-allow-origin: *
< cross-origin-opener-policy: same-origin
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< vary: accept-encoding
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< cf-cache-status: REVALIDATED
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=lwxePIlpj0QoXDil1hT4W%2Fzp9RVrEjh3shs%2B1oDs6ISuUrZckmX9myu2HAKLp2kovyTJSFapVBTu1JllBbY19DiLD2EjcNXa35kM7hwSlNeXJiLnv%2F3mL0NVsuGPLhE%3D"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 92040da9da673a05-YYZ
< alt-svc: h3=":443"; ma=86400
< server-timing: cfL4;desc="?proto=TCP&rtt=2014&min_rtt=1843&rtt_var=508&sent=5&recv=9&lost=0&retrans=0&sent_bytes=3403&recv_bytes=752&delivery_rate=1352747&cwnd=246&unsent_bytes=0&cid=7ddd4073d8862d76&ts=42&x=0"
<
[Body Omitted]
In this case there was no Accept-Encoding header and Cloudflare responded with uncompressed data (as expected). In cases where the “buggy cache entry” occurs like the original request shown, zstd is (unexpectedly) returned instead.
That is a flaw in my example. But this bug was noticed on iOS and it sets Accept-Encoding: gzip, deflate, br so it should not be getting a zstd response. So it is clear that this isn’t just occasional unusual handling of no Accept-Encoding header, it is much more general than that and compression negotiation seems to be skipped. If I see this bug again I will produce a log with an Accept-Encoding header for completeness. But I think given the shown behaviour and expected behaviour it is still clear that this bug exists.
