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
|