RE: Connection pinning (patch)

> -----Original Message-----
> From: Henrik Nordstrom [mailto:henrik@henriknordstrom.net]
> Sent: Thursday, 25 May 2006 12:24 PM
> To: Steven Wilton
> Cc: squid-dev@squid-cache.org
> Subject: RE: Connection pinning (patch)
>
> tor 2006-05-25 klockan 11:47 +0800 skrev Steven Wilton:
>
> > 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 peer is also part of the pconn key.
>
> Hmm here is a problem.. currently only the peer is included in the key
> on proxied requests, not the requested host, so if the same client has
> multiple pinned server connections then requests may be sent to the
> wrong pinned connection.. But the framework for including
> the requested
> host is also there. See pconnPush call in http.c.

Are you saying that, if this request is assigned to a different parent cache
(which can happen randomly), then the current code will never find the
persistent server-side connection?

Will the current 2.6 code handle this case gracefully? Or will it still
pass the connection on to the wrong server-side connection, and cause
problems in this case? I believe that my proposed patch causes better
behaviour in a single-level cache design, and does not break anything extra
in a multi-level cache design. Your proposal is a better solution because
it will handle this extra case.

> What about this:
>
> - Client and server connection should be marked pinned when there was an
> authenticated client request and the server responded with connected
> oriented auth message.. Not only because the server indicated connection
> oriented auth. Or to simplify when the server responds with connection
> oriented auth having auth data after the scheme (such data is only seen
> in response to a client auth request)
>
> - With the above in place the current flags assignment should work fine
> with no need for pconnLookup magic.

Wouldn't the connections need to be pinned when the server indicates
connection oriented auth so the client's request can go back to the same
server-side connection? If the client does not negotiate connection
oriented auth, the pinned flags can then be removed.

Steven

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.1/348 - Release Date: 25/05/2006