Learn how Cloudflare interacts with Entity Tag (ETag) headers set by your origin web server to ensure your resource versions cached in Cloudflare’s CDN match those cached in your visitor’s browser.
Overview
ETag headers identify whether the version of a resource cached in the browser is the same as the resource at the web server. A visitor’s browser stores ETags. When a visitor revisits a site, the browser compares each ETag to the one it stored. Matching values cause a 304 Not-Modified HTTP response that indicates the cached resource version is current. Cloudflare supports both strong and weak ETags configured at your origin web server.
Weak ETags
Weak ETag headers indicate a cached resource is semantically equivalent to the version on the web server but not necessarily byte-for-byte identical. Cloudflare supports weak ETag headers on all plans.
Strong ETags
Strong ETag headers ensure the resource in browser cache and on the web server are byte-for-byte identical. Domains on Enterprise plans enable strong ETag headers via a Respect Strong ETags Page Rule and lower plans customers can enable strong ETag headers using Cache Rules. Otherwise, strong ETag headers are converted to weak ETag headers. Also, set a strong ETag header in quotes (Etag: "example") or Cloudflare removes the ETag instead of converting it to a weak ETag.
Without a Page Rule, Cloudflare preserves strong ETags set by the origin web server if:
- the content is gzipped on the origin server,
- the origin sends the gzipped content with a strong ETag header, and
- Rocket Loader, Minification, Email Obfuscation, and Railgun features are disabled.