Robert Collins wrote:
> Persistence is fully "persistent connection" so it is exactly per client
> connection, and separately per upstream connection. So if client A can make
> one persistent connection and one non persistent connection to squid at the
> same time right? I'm not suggesting we alter that at all. I'm suggesting
> that when it is a persistent connection we only validate (which could be via
> helper or cached credentials) the Basic proxy-authorization header on the
> first request.
It is not per client connection, it is per hop. There might be any
number of hops between Squid and the client, and there is no way to
detect this reliably in the protocol.
> It's at squid discretion whether _squid_ requires further credentials.
Sure.
> I see little point - squid is not offering multiple realms for it's requests, so
> the user-agent (which is allowed to cache credentials) will be offering the
> exact same credentials on each and every request within the same connection.
Yes, but there is no guarantee that it is the same user agent which
sends the the next request on the same connection, unless you know for
sure that it is a direct connection from the client, and thiscannot be
detected reliably in the protocol.
> Thus unless squid is planning to offer different realms of
> proxy-authentication as challenges to different requests, squid should be
> confident that it is the same user agent on the existing persistent
> connection. NTLM makes this a requirement - which I don't like - but being
> able to do it is AFAICT within rfc 2616 and 2617.
As I sait it is not safe to make this assumption.
> Now regarding the headers
> proxy-authenticate
> proxy-authorization are hop by hop (rfc 2616 13.5.1),
> so it's at squid's discretion what resources require the proxy-authorization
> header, and the header is in rfc 2617.
Right. I missed this part, and unfortunately many proxies also disregard
this when forwarding requests to other proxies within the same
administrative domain.
A quite common setup looks like
client -> [workgroup proxy] -> [company proxy] -> internet
Where authentication is performed at the company proxy.
For Basic proxy authentication this is not a problem since it is
performed on a per message basis. For NTLM authentication or other
per-connection shemes this causes big problems due to the added hop.
> we're only talking basic auth with the proposed change so I'm skipping the
> Digest requirements (I'm looking at that as well but more on that later).
So what is your problem with looking at the basic proxy-authorization
header on sub-sequent requests on the connection? All known clients
automatically sends this blindly assuming the proxy requires it.
> So we are completely within the standard whichever way we do this - however
> the Proxy SHOULD allow all requests in it's realm to be valid for a set of
> credentials that passed one request (ie no more 407's, but 401's are
> allowed).
And all known clients already assures this by re-sending the credentials
without first waiting for the realm.
> Now the question is: once I authenticate a connection, does squid _allow_ me
> to change usercode mid-connection, and do the user-agents allow that?
User-agents do it if requested by the proxy, but AFAIK there is no user
agent where you can manually request a change (logout function is
missing in all known user agents).
> What I'm really suggesting is that squid only require Proxy-Authorization on
> the first request on a connection. It's neither in nor out of standard.
I'd say that it is more out than in of the standard since the RFC's
assumes a per message view, not per connection. And based on how the
current browsers behave I see no need for it.
/Henrik
Received on Tue Oct 17 2000 - 05:16:01 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:49 MST