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
Received on Wed May 23 2007 - 16:30:22 MDT
This archive was generated by hypermail pre-2.1.9 : Fri Jun 01 2007 - 12:00:05 MDT