How Vary: Accept Works When Serving AVIF Images

The Vary: Accept HTTP response header is a critical component of dynamic content negotiation, allowing web servers to deliver next-generation AVIF images to supported browsers while serving legacy formats like JPEG or PNG to unsupported ones from the exact same URL. By instructing intermediate caches and content delivery networks (CDNs) to store separate versions of a resource based on the client's Accept request header, it prevents caching conflicts where an unsupported browser might otherwise receive an unrenderable AVIF file.

The Challenge of Modern Image Delivery

AVIF (AV1 Image File Format) offers superior compression and visual quality compared to older formats like JPEG and WebP. However, because older browsers and some embedded web views do not support AVIF decoding, servers cannot blindly serve AVIF assets to all visitors under static URLs without breaking the user experience for a segment of their audience.

The Role of the Accept Request Header

When a modern browser requests an image, it includes an Accept header in the HTTP request detailing which image formats it can decode.

For example, a browser that supports AVIF will send:

Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

A client that does not support AVIF will omit image/avif from this list. The web server inspects this header to decide which format to return: an AVIF image if supported, or a fallback format like JPEG or WebP if not.

How Vary: Accept Manages Caching

Content delivery networks, reverse proxies, and local browser caches typically use the request URL as the primary cache key. Without intervention, if an AVIF-capable browser is the first to request /banner.jpg, the CDN would cache the AVIF response under that URL. A subsequent request from an older browser for the same URL would then receive the cached AVIF payload, resulting in a broken image.

The Vary: Accept header solves this by modifying the cache key generation:

1. Header Inclusion: When the server delivers an image based on the client's format support, it includes Vary: Accept in the response headers.
2. Composite Cache Keys: The caching layer notices the Vary: Accept directive and constructs a cache key that combines both the URL and the specific value of the client's Accept header.
3. Partitioned Storage: The cache stores the AVIF version for requests advertising image/avif support and a separate JPEG or WebP version for requests that do not.
4. Appropriate Delivery: Subsequent requests are matched against both their URL and their Accept header, ensuring clients only receive cached versions they can properly display.

Best Practices for Implementation

To make Vary: Accept work efficiently:

• Normalize the Accept Header at the CDN Level: Different browsers send slightly different Accept strings, which can cause excessive cache fragmentation and lower cache hit ratios. Configure your CDN or edge proxy to normalize the incoming Accept header into standardized buckets (such as avif, webp, or default) before forwarding it to the origin or evaluating the cache key.
• Combine with Correct Content-Type: Always ensure the server pairs Vary: Accept with the correct Content-Type: image/avif response header so the client correctly parses the incoming byte stream.