There was a thread in June or 2013 regarding cache invalidation of multiple media types. (thread: http://mail-archives.apache.org/mod_mbox/trafficserver-users/201306.mbox/%3ccdd7790c.27424%[email protected]%3E)
Summary of the initial question (Steve Owens): Is there a configuration (Vary header, proxy.config.http.cache.vary_default_*, etc) that would cause that a PUT or POST on a specific URL would cause a cache invalidation on all variant media types of that URL? Summary of ultimate response (Leif Hedstrom): This sounds like PURGE, but not currently in PUT or POST. We could look at putting that behavior into PUT/POST. My revisit: Has any action been taken on this? (I have searched the changes.log and not found anything pertinent, but it is possible that I missed something) I have a REST api serving data with both 'application/json' and 'application/xml' content-types for each URL. Different clients will consume one or both of these content-types. When a POST is invoked with 'application/json', my assumption is that the cache server should invalidate the object for 'application/xml' as well, as this is a variant representation of the same object. In my testing, I consistently get unexpected (according to my understanding and expectations) results: Here's a summarized log of what I see GET application/xml TCP_HIT baseline GET application/json TCP_HIT baseline POST application/xml TCP_REFRESH_MISS expected GET application/json TCP_HIT unexpected/incorrect/stale data GET application/xml TCP_MISS expected GET application/xml TCP_HIT expected I have tried setting the 'proxy.config.http.cache.vary_default_text' and '...vary_default_other' to Accept, and also setting the Vary header to Accept in my response, all to no avail. I have also tried Accept values of "text/html", "text/json", "text/xml", "text/plain" - in case th e'proxy.config.http.cache.vary_default_text' only looks at 'text/' media type prefixes, also with no luck. (Based on ATS documentation, and other sources, I am lead to believe that the correct header to Vary on is Accept, as opposed to Content-Type. Correct?) I have confirmed that I can invoke a 'PURGE' on the URL, which will cause desired end-results, but this requires that upon any PUT/POST request, I will need to, as part of my processing, explicitly invoke a PURGE in code to invalidate the cache for that object, which is undesirable. For some developers/situations, it may even be prohibitive. Is there plans to change the behavior in a future release, or am I stuck with self-invoking a PURGE request inside code handling my PUT/POST request? Or are there other options for configuring this that I have not found/tried? Thanks -Norm Paxton NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
