trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Cache invalidation
Date Sat, 08 Jun 2013 15:34:09 GMT
On Jun 7, 2013, at 11:53 AM, "Owens, Steve" <Steve.Owens@disney.com> 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
header.

> 
> 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 ...

J
Mime
View raw message