Re: problems with the squid-2.5 connection pinning

----- Original Message -----
From: "Henrik Nordstrom" <henrik@henriknordstrom.net>
To: "Adrian Chadd" <adrian@creative.net.au>
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