On Fri, 1 Apr 2005, Matt Hamilton wrote:
So, are there any other efforts at implementing connection pinning?
Not that I know of. Anyone else know anything being done in this area?
If this is something that we want to implement, is there a particualar place we should start?
In pretty much the same places you have been already I think.
Things you need is to (in priority order)
1. in the HTTP server side code, look for the NTLM or Negotiate authentication scheme in the server reply. If found remember that you ned to use connection pinning for this connection.
2. when done with fetching the reply, instead of giving the server connection to pconn, associate it directly with the client connection as a pinned connection.
3. When initiating forwarding of the next HTTP request, first check if there is a pinned connection already associated with the client connection. If there is use this(after verifying that the new request is for the same server obviously...). don't forget to take note that this is a pinned connection and should be acted on by '2' above (the next reply may not have any NTLM/Negotiate header to detect by '1')
4. To avoid the risk of filedescriptor leakage, when detecting that the server connection should be pinned the first time add a close handler on the client connection forcing the server connection to be closed when the client connection is.
5. While the connection is idle, keep monitoring it for closure like pconn does. If you see that the server connection is closed, close the client connection.
6. When detecting NTLM/Negotiate authentication from the client while reading/parsing the client request, make sure to note this on the client connection and use this fact to forcibly disable pipelining of requests from this client connection. (pipelining is normally disabled, but may be enabled in squid.conf which would cause serious headache for connection pinning if allowed..).
Regards Henrik
