According to Oleg Bartunov:
> Hmm, very interesting solution but I can't explain every user
> please configure your browser in special way to browse my site.
I didn't mean that was a solution - just that I set everything
up according to directions and it did cache when it had an
explict proxy request from a client, but I still didn't get
the internal proxy requests to cache. Not much of my dynamic
content could be meaningfully cached anyway so it is working
out pretty well to have a strict split between static files
and uncached proxy passthrough. There are a couple of exceptions
where I rebuild static files every few minutes. If I had a
lot of those I would probably work harder on controlling a
cache.
> The problem becomes more complex if we'll take into account
> not only proxy cacheing feature but also clients browser
> cache.
It turns out to be hard to get this exactly right. Most clients
won't cache anything with a '?' at all and intermediate caches
have differing policies about /cgi-bin/ and other well-known
hints about dynamic content. Also the original Expires: header
uses the clients concept of time which may not match yours
(and there is a bug in an old version of Netscape that causes
it to reload animated gifs for each animation step if an
Expires: header is present). There are now Cache-Control: headers
that give a finer grained control but not everything uses them.
Les Mikesell
[EMAIL PROTECTED]
