On Jun 7, 2013, at 11:53 AM, "Owens, Steve" <[email protected]> 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
