trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: Cache invalidation
Date Sat, 08 Jun 2013 15:34:09 GMT
On Jun 7, 2013, at 11:53 AM, "Owens, Steve" <> wrote:

> One of the issues that comes up over and over again with regard to cache
> invalidation is that the HTTP spec automatically invalidates the cache
> when an unsafe operation such as PUT, POST or DELETE is called upon a URI.
> I am not sure about this and I am certainly open to correction, but I
> believe that ATS uses the Content-Type as part of the cache key.

I believe that ATS will store alternate versions of a document my varying on the Content-Type

> So if for example I were to call
> GET .../users/xyz222
> Accept: application/json; model=com.bla.bla.User.address
> The result would end up in one cache entry.
> And if I were to call
> GET .../users/xyz222
> Accept: application/json; model=com.bla.bla.User.credentials
> The result would end up in a different cache entry.
> What would be fantastic however is if I could some how configure ATS such
> that if it were called with
> PUT .../users/xyz222
> Content-Type: application/json; model=com.bla.bla.User.address
> That any content at .../users/xyz222 would be cache invalidated regardless
> of the content type delivered.

I'm not sure how freshness is handled with alternates, but could you explain why this is a
problem? Does the origin return different Cache-Control information for different content
types? I'd expect the different content types to be cached consistently, so that when one
is stale, all the others are stale as well ...

View raw message