Check compression transformations before requiring a strong Cloudflare ETag

A strong origin validator can become weak when the delivered representation changes.

Source facts

Cloudflare distinguishes strong ETags, which identify byte-equivalent representations, from weak ETags, which indicate semantic equivalence. Its documentation shows compression and visitor Accept-Encoding combinations where strong tags are weakened. Enabling Respect Strong ETags also disables specified transformation features, so that choice has effects beyond the response validator itself.

Source: Cloudflare — Using ETag Headers with Cloudflare.

Applicability

This concerns Cloudflare handling of origin ETags.

DSE recommendation

DSE recommends deciding whether the application needs byte-level identity or semantic revalidation before changing validator settings. Inventory response transformations and compression at origin and edge. Avoid forcing a strong label onto content whose bytes were changed in transit. Review the documented feature changes when enabling Respect Strong ETags and coordinate them with the website owner rather than treating the setting as an isolated cache optimization. Have the website owner approve the transformation features affected by the setting before deployment. Keep a byte comparison for one encoded and one unencoded path beside the validator result. Reopen the decision when compression policy changes rather than treating a previously observed strong tag as permanent.

Verification

For a controlled resource, compare ETag, Content-Encoding, and actual bytes through representative accepted encodings. Exercise a conditional request and verify the intended 304 or replacement behavior. Record both the configured transformation policy and observed validator strength, and test any disabled website features before adopting the setting broadly.

Official reference

Cloudflare — Using ETag Headers with Cloudflare. Reviewed October 20, 2026.