Wow There is way to process easily, great.. Eric iPhone
2011. 10. 31. 오전 1:34 "Henry C." <[email protected]> 작성: > 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 >
