Alex Rousskov wrote:
On Mon, 2008-09-22 at 00:07 +0800, Adrian Chadd wrote:
Its a 900-odd line patch; granted, a lot of it is boiler plate for
config parsing and management, but I recall the issues connection
pinning had when it was introduced and I'd hate to try and be the one
debugging whatever crazy stuff pops up in 3.1 combined with the
changes to the workflow connection pinning introduces.
It would help if there was a document describing what connection pinning
is and what are the known pitfalls. Do we have such a document? Is RFC
4559 enough?
I think RFC4559 is enough and it is small enough if someone want a quick
view. The only does not document well in this document is what will
happens if more than one proxy servers used ("Connection: Proxy-Support"
header)
If not, Christos, can you write one and have Adrian and others
contribute pitfalls? It does not have to be long -- just a few
paragraphs describing the basics of the feature. We can add that
description to code documentation too.
The problem with negotiate authentication mechanism (NTLM and Kerberos)
is that it does not authenticate the client request to the server but
each client connection to the server separately. At the beggining of
each connection (I mean low level connection, a socket connection) to
the server the following conversation required:
1st Step
=========
client to server: GET dir/index.html
Server to client response:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
Here the server saids that authentication required.
2nd Step
=========
client to server:
GET dir/index.html
Authorization: Negotiate a87421000492aa874209af8bc028
server to client:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate 749efa7b23409c20b92356
Client send required authentication data and server respond with its
authentication data
3d Step
=======
Client to server:
GET dir/index.html
Authorization: Negotiate 89a8742aa8729a8b028
Server to Client response:
HTTP/1.1 200 OK
WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca
Normal response......
Client produces the final authentication data and send new request to
the server which if the credentials are OK respond with "200 OK"
Now when a proxy server exist between client and server the SAME
connections pair, lets say the client-to-proxy and proxy-to server
connections pair, MUST used for any request tunneled through the
client-to-proxy connection, else the authentication will fail.
Also the proxy must send the "Proxy-support:
Session-Based-Authentication" header with its responses to the client so
the client know that the proxy supports session based authentication
(connection pinning).
So the connection pinning project try to correlate the client-to-proxy
and proxy-to-server connections and use always the same pairs for client
requests to the web server. (and it is difficult to debug it because
after a successful test still you are not sure if the pinning code
worked or you was jsut "lucky" and the same pairs used :-( ...)
Some extra notes about "Proxy-support" header. This header is hop-by-hop
header, so if there are more than one proxy servers in the chain must
removed before the http response forwarded to the next hop (and created
again if the proxy server supports negotiate authentication). This is
why the "Connection: Proxy-support" header required (if the
Proxy-support string included in the list values of the Connection
header will remove any header named Proxy-support from response
headers). This is proposed by Henrik to the authors of the RFC when the
rfc4559 was still draft but it is not included in the final RFC document.
I don't pretend to completely understand the implications for ICAP
either. Is there any documentation for how connection pinning should
behave with ICAP and friends?
I think there is not any need for special handling for ICAP unless we
are planning to support Negotiate authentication on ICAP servers. In
this case we maybe should extend connection pinning to the ICAP server
connections too. But I am not seeing any requirement at this time.....
ICAP and eCAP do not care about HTTP connections or custom headers. Is
connection pinning more than connection management via some custom
headers?
Yes it is something more but I think ICAP should not care about
connection pinning...
Is there any particular rush to get this in for this release at such a
late point in the release cycle?
Sine NTLM authentication forwarding appears to be a required feature for
many and since connection pinning patch is not trivial (but is not huge
either), I would rather see it added now (after the proper review
process, of course). It could be the right icing on 3.1 cake for many
users. I do realize that, like any 900-line patch, it may cause problems
even if it is reviewed and tested.
I hope I am not confusing the squid developers and I explained a little
the connection pinning problem ...
Regards,
Christos
Thank you,
Alex.
