Finally did hunt down the cause of the problem. Glad to report it wasn't ATS related.
Turns out, our third party CMS had started flushing HTTP responses before our end-of-reponse header setting was processing. We've since adjusted our code to fire earlier in the request and voila, problem solved. On Feb 25, 2014, at 2:04 PM, Brendan Webb <[email protected]<mailto:[email protected]>> wrote: I've recently started to notice that some requests made by ATS to my origin servers are completely missing the Cache-Control header in the response. Functionality seems unaffected, but the missing header is somewhat concerning. Wondering if others have seen this behavior too as I'm having a heck of a time tracking down the cause. Things I've done recently which may have caused this: * upgraded ATS from 3.0.4 to 4.1.2 * switched remap.config from using map/reverse_map combos to one way map + pristine host headers * using rfc5861 plugin for stale-while-revalidate and stale-if-error functionality Hmmm, not sure what ATS possibly could do to prevent the origin from sending the Cache-Control: header. Are you sure it’s not something on the origin side that’s trying to detect the UA (maybe using the Via: header?) and responds without the CC: ? — Leif
