You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by "Owens, Steve" <St...@disney.com> on 2013/06/07 20:53:56 UTC
Cache invalidation
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?
Re: Cache invalidation
Posted by Leif Hedstrom <zw...@apache.org>.
On 6/7/13 12:53 PM, 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.
>
In addition to what James said, and asked, couple of thouhts:
1) We don't use Content-Type as part of the cache key. It might be part of
the alternate selection portion.
2) Am I correct in that are you are asking for PUT/POST to invalidate all
alternates, regardless of what the Content-Type is?
For 2), if that is correct, this sounds an awful lot like what we did for
PURGE requests. See e.g. https://issues.apache.org/jira/browse/TS-789 and
git show 0188c46592f15c44813275fa5755acf8db0cca5b . Obviously those changes
don't apply to PUT and POST requests, but if this is what you are asking
for, I think that's fine to fix (but, we should probably check the RFC too).
Cheers,
-- Leif
Re: Cache invalidation
Posted by James Peach <jp...@apache.org>.
On Jun 10, 2013, at 10:02 AM, "Owens, Steve" <St...@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" <jp...@apache.org> wrote:
>
>> On Jun 7, 2013, at 11:53 AM, "Owens, Steve" <St...@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
>
Re: Cache invalidation
Posted by "Owens, Steve" <St...@disney.com>.
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" <jp...@apache.org> wrote:
>On Jun 7, 2013, at 11:53 AM, "Owens, Steve" <St...@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
Re: Cache invalidation
Posted by James Peach <jp...@apache.org>.
On Jun 7, 2013, at 11:53 AM, "Owens, Steve" <St...@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
Re: Cache invalidation
Posted by "Owens, Steve" <St...@disney.com>.
"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" <St...@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?
>