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 Mon, 10 Jun 2013 21:37:27 GMT
On Jun 10, 2013, at 10:02 AM, "Owens, Steve" <Steve.Owens@disney.com> wrote:

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

Thanks for the explanation Steve! To clarify one more thing ... did you test the Traffic Server
behaviour WRT invalidating requests? What happened?


> 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