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.

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

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.

And I'd still like to see a close handler installed on the client
connection closing the pinned server connection(s) when the client goes
away.

Proposed implementation:
 * small cbdata protected struct linking the two
 * close handlers installed on both fd:s
 * Close of client-side remembers the server-side fd in a local
variable, cbdataFree the struct and closes the server-side.
 * Close of server-side unregisters the client-side close handler and
cbdataFree the struct.

Issue: How to link the two.. Is there a place where we have both?
Probably need to extend the request_t with a reference to its
originating client connection (cbdata protected).

  req->client_conn = conn;
  cbdataLock(req->client_conn);

in the request free

  cbdataUnlock(req->client_conn);

and in the code needing to find the client connection from the request

  if (cbdataValid(req->client_conn) {
      ....
  }

Regards
Henrik