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 Mon, 10 Jun 2013 17:02:26 GMT
Per HTTP 1.1 Specification 13.10

"Some HTTP methods MUST cause a cache to invalidate an entity. This is
   either the entity referred to by the Request-URI, or by the Location
   or Content-Location headers (if present). These methods are:

      - PUT
      - DELETE
      - POST
"

So at least according to the HTTP specification if a resource exists at a
given URI with multiple formats, my reading of the Http specification says
that this is the behavior that ATS should exhibit if it is to be in
compliance with the spec.

As to why this is important.  If I have a resource at a particular URI and
that resource is able to be returned with different representations for
example:

Representation 1: 

GET .../my/resource/<id>
Accept: application/json; model=resource.summary

GET .../my/resource/<id>
Accept: application/json; model=resource.epilogue

GET .../my/resource/<id>
Accept: application/json; model=resource.all

GET .../my/resource/<id>
Accept: application/xml; model=resource.all




If the resource has a portion called a summary then the summary would be
returned by the first call.  If the resource has an epilogue then the
epilogue would be returned by the second call, and finally the third call
would return the resource in it's entirety, so would call 4 but in a
different format.

Now if I do an:

PUT .../my/resource/<id>
Content-Type: application/json;

Then the expectation is that the server would update the resource with
whatever data was sent in the put.  All forms of the resource at the given
URI would be invalidated.





On 6/8/13 8:34 AM, "James Peach" <jpeach@apache.org> wrote:

>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