Rolling out the use of 'Edge-Cache-Tag' on already cached resources

I am delivering some images through a web service.
Here below the scenario with a dummy resource example: /api/myimage

Step 1

I have 2-minute cache in the Akamai edges and downstream cache.

Step 2

My clients download my resource /api/myimage and, when the Akamai cache expires, they perform an HTTP request with the ETag header.
My API returns

  • a 304 if the resource is not been changed
  • a 200 with the new resource if it’s changed

Step 3

Now I am improving the service returning the Edge-Cache-Tag header.
In this step the Akamai and downstream cache is still at 2 minute.

Step 4

I change the Akamai caching value to 1day keeping the downstream cache to 2 minute.

Step 5

I change the resource /api/myimage and I send an invalidation request with the given tag.

What is the expected behavior?

I believe it depends on the edge caching state.

If the edge has stored in the cache the resource without the Edge-Cache-Tag header and it has continually revalidated it, the edge has no knowledge of the Cache-Tag I set.

If the edge has stored the original resources without the Edge-Cache-Tags and then, for some reason, it has removed it from the cache and then requested it again with the Edge-Cache-Tag, when I call the API I will purge it from the cache.

Could you please confirm the behavior or explain to me what should happen in the above scenario?

Looking at the edge header behavior I see that if I change a header in the 304 response it will not change the cached value.

All the best


Edge-Cache-Tag headers have priority over the other caching headers.

What I recommend to do, is to do a one-time URL invalidation of the cache for /api/myimage. That way, that URL gets invalidated from Akamai cache everywhere. Perhaps the delete URL purge option is even better.

That way, any new request for that object will have to be retrieved from origin with the proper Edge-Cache-Tag and you can 100% guarantee that all copies of the URL/object have the Edge-Cache-Tag attached to it.

That said, I will have to verify this, but I believe that on revalidation through a 304 If Modified Since request, the Edge-Cache-Tag headers would be retrieved from origin as well.

I hope that helps. /Mike

Hi Mike, thanks for the answer.

We are already returning the 304 with the cache tags but I think that a missing cache update we had was caused by the unprocessed cache-tags on 304 and I want to make the proper change because that will not happen again.

I have also observed that, in general, the headers returned by a 304 are ignored and the users continue to get the headers returned by the original 200 response.

Probably you are right about the URL purge but it will cause a high load on the origin side.

Let me know if you have any further information about the processing of the Edge-Cache-Tag on 304 response.

Thanks a lot