trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Owens, Steve" <Steve.Ow...@disney.com>
Subject Re: Cache invalidation
Date Fri, 07 Jun 2013 19:00:24 GMT
"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."

Poorly worded above paragraph.  Better worded as follows:

"One of the issues that comes up over and over again with regard to cache
invalidation is the invalidation of related items in the cache. The HTTP
spec automatically 
invalidates the cache when an unsafe operation such as PUT, POST or DELETE
is 
called upon a URI."




On 6/7/13 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.
>
>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.
>
>
>Thoughts?
>


Mime
View raw message