Henk-Jan Kloosterman wrote:
> > Hmm.. maybe there are a proxy_auth cache defiency there. In theory the
> > first request carrying the new passphrase would be sent to the
> > authenticator, but maybe all are until the authenticator returns. Need
> > to check the code on this.
> >
>
> If you could to that please, cuase I am running out of options right now.
> I checked in cachemgr.cgi: In authticator sttistics the average service time
> is 1830 msec
I have, and there sure is a small window when the ttl expires which
allows for multiple lookups and possibly even a minor proxy_auth cache
inconsistency (minor == might repair itself after a while and should
have no bad effects apart from a few extra bytes of memory used).
> I am not sure, but it looks like it happens if the user hasn't used the
> browser for a longer period (shorter then 3600 secs) I will try to check. Do
> you want more info?
It should be at least 3600 seconds from when the user user first was
authorized (the proxy_auth helper last returned OK).
What you can do until a patch is provided is to further upper the TTL,
which is probably a good thing anyway as HTTP is not really designed for
password changes like this sporadically (every 3600 seconds) in the
middle of a surfing session.
a) The browser is in the middle of fetching a page with X objects left
to retreive
b) The TTL expires, causing Squid to requery the authentication helper
which will tell that the password is invalid (still the old password).
Squid will then send "407 Proxy authentication required" to all those
requests.
c) As the browser has multiple concurrent 407 replies from the proxy, it
might well pop up several login dialogs to the user. But this is
user-agent implementation details..
-- Henrik Nordstrom Squid hacker -- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Fri Dec 22 2000 - 15:01:34 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:06 MST