----- Original Message ----- From: "Henrik Nordstrom" <[EMAIL PROTECTED]>
To: "Adrian Chadd" <[EMAIL PROTECTED]> Cc: <squid-dev@squid-cache.org> Sent: Friday, April 14, 2006 5:32 PM Subject: Re: problems with the squid-2.5 connection pinning
Was anything ever written to define/clarify the semantics of connection pinning (at least for NTLM authentication) ? I couldn't find anything with a quick browse with google defining the behaviour (so I could see how the error condition should be handled.) Let me know when you have something and I'll test it out.If the server connection is gone we have little choice but to close the client connection as well. This due to the client considering that connection already authenticated and sending a new authentication challenge on the same client connection would be considered by the client as "access denied for this user, ask the user if he has another login which might be granted access to the requested object".
Is it really a problem if the client is sent a new auth challenge? If the client connection is closed because the server went away, the client will most likely need to refresh the page, which will result in a new auth challenge being issued anyway.
If there are any other issues raised by keeping the client connection open, these other issues would be good reason to close the client connection.
We've been using a patch that allows NTLM auth to work through our proxies for a while now. The version we're using does depend on the tproxy patch that we've also applied, and it essentially adds the client's ip address and port to the pconn key when the server connection is spoofing the client's ip address. As a result of using the existing pconn code, we do not handle the closing of the server connection any differently from any other persistent connection failing. This has not generated errors that I have heard of from any client using our proxy servers, and we do transparently proxy all our client access to web servers.
Having seen your patch, I've added the Proxy-Support: headers, and also added a "pinning" flag to the request->flags struct to allow identification of a pinned connection. I've attached a modified version of the patch we're using for comment, as it uses the existing persistent connection methods and does not add any new sections of code that will terminate connections (and this version will apply to the squid 2.5 tree without needing the tproxy patch applied).
I've not looked into the http specs to see if I'm breaking any rules here, but in practice we're not seeing problems with this style of connection pinning.
Steven
pinning.patch
Description: Binary data
