What are the uses for If-None-Match with multiple entities?

Question

I'm using the ETag header for caching and the browser sends a corresponding If-None-Match header. Initially, I simply compared these headers and it worked.

Later it occurred to me that rfc2616 allows a list of entities, so I fixed it. The question is, if the fix gets ever used...

• Does the browser ever issue a request with an If-None-Match header containing more than one entity?
• Are there any other real world uses?

Answer 1

There are two use cases that I can think of: union of browser and caching proxy entity-tags and custom client-side cache implemenation.

Although, I never seen browser serves request with multiple entity-tags in If-None-Match, there are caching proxies that may have it's own version of a requested resource. They may replace value of If-None-Match sent by browser with union of browser's resource version entity-tag and proxy resource version(s) entity-tag before sending request further to server. This way if proxy has fresh version of a requested resource you can reduce server load by serving full response (with body payload) from proxy instead of a server. This case is described by RFC 7234 Hypertext Transfer Protocol (HTTP/1.1): Caching:

When a cache decides to revalidate its own stored responses for a request that contains an If-None-Match list of entity-tags, the cache MAY combine the received list with a list of entity-tags from its own stored set of responses (fresh or stale) and send the union of the two lists as a replacement If-None-Match header field value in the forwarded request.

I can't say whether support of that part of RFC 7234 is wide, but certainly there are proxies that support it. Check Node.js Caching Reverse HTTP Proxy project by Colin Mollenhour.

On the other hand you may not want to rely on browser to perform conditional request. You can set If-None-Match HTTP header value by yourself using XMLHttpRequest.setRequestHeader(). This can be useful if you store multiple versions of a resource using Web Storage API, Cache API or other mechanism. Server response must contain ETag HTTP header with entity-tag. This entity-tag indicates which version of a resource is considered fresh.

Answer 2

I've been reading a lot about caching mechanisms recently and found myself asking this very same question. I can think of only use case (in addition to the ones Leonid mentioned) where it would make sense to store and send multiple ETags : when a ressource rollbacks.

It could be accidental, such as an api that serves json, and the underlying data gets updated often, in ways that it gets restored to a previous version.

But it could also be by design, where a big configuration object would have only a few different versions possible, that would get switched a lot. (the frequency at which it would be changed is important, otherwise caching wouldn't bring a lot value). In this case, caches would be happy to have all available versions always ready to be served.

I know that's a long shot, and I can't think of any real situation that would fit one of these. Besides, revalidation suck anyway, cache hits are the way to go =)

Also, you might wanna read this. It appears all caches store only the last sent ETag (which is comprehensible for obvious memory reasons).

Hope this helps