RE: Connection pinning (patch)

> -----Original Message-----
> From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net]
> 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