On Sat, October 29, 2011 15:59, Igor GaliÄ wrote: >> ie: >> browserX loads and caches page1. browserY loads page1, but for some reason >> the cached page1 is not served. >> >> /me wanders off to stare at more HTTP headers, ... >> > > Maybe instead of staring at them you might want to share them with > us so we can help you :)
Hi Igor, Nothing to do with dynamic URLs... It turns out that proxies (ATS included) are respecting some or other RFC to identify cache objects based not only on the requested URL, but also on the requesting HTTP headers. I confirmed this by using several machines and making sure that each was using the *exact* same browser user-agent/cache headers. When I did this, the cached object was served up to all the clients, irrespective of who cached the object. Anyway, I never did solve this problem completely (I didn't need to, luckily) - I have a query page which receives requests, it then uses PHP's curl to fetch (via the same ats cluster which customers hit) a resource-expensive object from back-end servers. That last request always uses the same user-agent/cache headers (curl), so it is *always* the same irrespective of the original request from the client who hits our servers from the outside; because of this the heavy objects are cached beautifully by ats /sidebar: it would be great if ats had a config option to "normalise" these headers so that an object is seen as cached by all clients. That would probably break something or other, I suppose. However, for our case, it's a deal-killer NOT having it. Fortunately we could work around this limitation. Apologies if my description was a bit disjointed. -- Regards Henry
