Re: Connection pinning (patch)

tor 2006-05-25 klockan 08:38 +0800 skrev Steven Wilton:

> By peers do you mean parent peers? I would assume that once the auth flag
> is set on the request, it would not go via any sibling peers.

Yes.

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

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

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

> We still set the auth flag before httpCachableReply() is
> run, so this new object will not be cached.

Yes.

Regards
Henrik