Re: problems with the squid-2.5 connection pinning

lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton:

> 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.

Yes, but here the client expects the auth challenge.

The problem with sending a new auth challenge on an already
authenticated NTLM/Negotiate is that as far as the client knows this
connection to the web server is already authenticated, and receiving a
new auth challenge on the same connection can only mean that the
previously sent credentials isn't acceptable for the requested object
and the end-user has to be queried for a new login.. or at least so is
the principle behind how authentication works in HTTP. Now with
Microsoft already ignoring the specifications in many other aspects they
probably ignore this as well..

Closing a persistent connection at any time after the previous reply has
been sent is something clients working with persistent connections MUST
handle, and the client SHOULD automatically retry the request in such
situation (with just a few exceptions like POST/PUT where the end-user
SHOULD be queried if the operation should be retried)

> 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.

Good. This would simplify things quite a bit.

> 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).

Great!

> 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.

The whole idea is outside of specs anyway.

Regards
Henrik