Henrik Nordstrom wrote:
mån 2007-05-21 klockan 17:39 -0400 skrev Benno Blumenthal:
But I wrote in part because I couldn't be sure which way ignore-auth was
intended: it would be nice if the documentation were explicit about the
header equivalent.
It's intended for public material on an authenticated server. I.e. where
the server should have responded with "Cache-Control: public" to allow
caching even if the request included authentication credentials.
Hmm.. you are right. The documentation in squid.conf.default is a bit
misleading on this. I'll fix it up.
ignore-auth caches responses to requests with authorization,
as if the originserver had sent ``Cache-control: public''
in the response header. Doing this VIOLATES the HTTP standard.
Enabling this feature could make you liable for problems which
it causes.
Fixing the documentation is a fine solution, but I wanted to explain my
thinking before dropping the subject entirely. First of all, my squid
is being accessed by multiple users.
The pair of header lines
Cache-Control: public
Vary: Authorization
as you pointed out, this allows caching on a per user basis, for Basic
Authentication and for Digest Authentication if the client does not
supply an cnounce.
(As it happens, I get data from some places with basic authentication,
and some data from places with a slightly modified digest authentication).
I do this not because I want the user stuff cached separately per se,
but because I want Authentication to work, i.e. I need the challenge
pages so that the source server can validate users. If I do the following,
Cache-Control: public
Vary: none
Then the first user that gets a protected page will prevent the
challenge from being sent to all subsequent users, breaking
authentication for that page. So no server that wants authentication to
work would ever set headers this way. I can get around it in my case
because I know which request is made first in the set, so I can just
write my refresh_pattern to not cache that (i.e. no ignore auth) and
authentication works, the significant payload being in the subsequent
requests (which have an ignore-auth and cache). As much as I hate to
admit it, your way actually works better for me, because the subsequent
requests are cached across users, which makes up for the one page type
not getting cached. But it is a fussy configuration -- for most people
using ignore-auth will simply break authentication unless they really
know what they are doing. Thus the extended documentation.
Meanwhile, the real solution is to get the data server to put the right
headers on -- I'll keep working on that.
Thanks,
Benno
