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