trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry C." <he...@cityweb.co.za>
Subject Re: Trying to understand caching inconsistency with dynamic URLs (or cookies)
Date Sun, 30 Oct 2011 16:34:56 GMT
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