trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Ahn <byungwook....@gmail.com>
Subject Re: Trying to understand caching inconsistency with dynamic URLs (or cookies)
Date Sun, 30 Oct 2011 19:05:19 GMT
Wow There is way to process easily, great..

Eric iPhone

2011. 10. 31. 오전 1:34 "Henry C." <henka@cityweb.co.za> 작성:

> 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
> 

Mime
View raw message