> -----Original Message----- > From: Henrik Nordstrom [mailto:[EMAIL PROTECTED] > Sent: Thursday, 25 May 2006 9:22 AM > To: Steven Wilton > Subject: Re: Connection pinning (patch) > > > What do you think of the attached patch then? > > Doesn't work for the reason you mention below. And when thinking about > that problem it is actually larger. > > We need more information in the client connection to do this > correctly, > not just a "pinned" flag. What we need is all the data making up the > pconn key of the pinned connection. > > The more I think about this, the more convinced I get that the tightly > coupled approach is the correct one. It allows immediate bypass of all > of these complications in form of peers etc.
The problem with this approach is that it is possible for a single client HTTP connection to have multiple server-side pinned connections. If the client has proxies set, then requests for multiple servers will potentially be requested from a single client->proxy tcp connection. To do this properly you would need to have a list of pinned server-side connections attached to a client socket. The advantage of this approach is that you can correctly identify all pinned server-side connections, and you can close then all when the client socket is closed. > Consider for example a setup having two parents in round-robin mode. > With the current decoupled approach this can't be made to work as the > NTLM negotiation will nearly always be split in half with the initial > negotiate packet taking one path and the auth response taking another > (which will then get rejected as invalid as it doesn't match the > challenge on the other path).. Are you sure that this will happen? Once the NTLM auth header is seen, won't the the cache<->peer connection get pinned to the client<->cache connection? (ie the pconnPush includes the client ip/port as part of the key)? > > The only downside that I can > > see from this patch is that squid may try to request the > object from a peer > > first because the auth flag is not set when the > clientHierarchical() > > function is run. > > Right. But the request does not carry any authentication so it's OK. > > Pinning should be initiated by the client sending a > NTLM/Negotiate/Kerberos authentication request and confirmed by the > server responding to it with authentication details. Until then all we > should do is to announce that we support connection oriented auth. > > If the server connection is lost after this the process > simply restarts. The second patch posted would request the object from a sibling cache, and presumably it would not find the object (because it would have been marked as uncacheable because the auth flag is set when the object is actually fetched). If the object has previously been cached (ie it is available on the unauthenticated part of the web server), we would potentially get a hit on the object and send it to our client. I don't see this behaviour as being broken in any major way. If the object is not in our cache, or a sibling cache, we will request the object ourselves with the auth flag set, which will stop the object from being cached. A second option would be to wrap the pinning code in some #defines and note that it does not work with parent caches. This way people can enable it if they want NTLM auth to work, knowing that it will break with multi-level caching. Steven -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.7.1/347 - Release Date: 24/05/2006
