Using ETag Headers with Cloudflare
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.