Re: domain attribute in digest auth

> > I don't see why the semantics should be any different from those for
> > server auth - the (host port realm) tuple defines the 
> > protection space,
> > with the domain attribute as a means for extending that to a
> > (list-of-hosts list-of-ports realm) (the host and port here just refer
> > to the proxy's host/port instead of the server's host/port, 
> > that's all).
> 
> I think I finally see what you're talking about. I think you've got a
> fundamental misconception here. (Or maybe I do.) You're conflating proxy
> host/port and origin server host/port. The protection space IS NOT defined
> by the host name of the proxy; it is defined by the host/port part of _the
> URI being accessed_.

But, but, but, ... I just looked at the spec again and I don't see it
saying that (but I don't see it saying what exactly the protection
space for proxies is). Yes, my client works like I said above.
Interestingly, I just tested Netscape (4.05) and it also works the way
I understood it (btw., it will handle multiple credentials for multiple
proxies, i.e. you are only prompted once for each proxy). I don't know
of any other clients which handle multiple proxies except for IE - that
one somebody else would have to check.

> That's why I thought that "domain" had no meaning for
> proxies. What you are proposing is a new definition of _protection space_
> for proxies, one which seems (on my first examination) to allow "domain" to
> make sense for proxies.

Ok, I see where we were missing each other. I agree, if you use the
server's host/port then the domain attribute does not make sense (and I'm
not sure how to make it make sense).

> However, the spec is in last call to move forward to Draft Standard. I don't
> think this comprises a bug, but an extension. You appear to have thought
> that this was the way it worked before, but neither of the active authors,
> nor the people who asked us to clarify what "domain" meant for proxies,
> thought so. So, I will go back to my offer of making "domain" illegal for
> proxies (as an editorial change), so that the way would be clear for your
> extension to be implemented once it has been considered.

However, as noted above, there are at least two implementations which
think the host/port refers to that of the proxy. The problem is that I
think the two interpretations are mutually exclusive, i.e. if we make
the protection space always consist of the server's host/port then I
don't see how we can extend that in the future to work differently.

I understand that the spec is in last call, but this problem must be
solved correctly - the protection space for a Proxy-Auth must defined much
more clearly. I think it makes more sense to use the proxy's host/port
instead of the server's for Proxy-Auth, but I'd like to hear from others
on the list. In any case, which ever solution is taken it can be
construed as a significant change to the spec (depending on what your
interpretation was before) and therefore we should choose a solution
based on what makes sense, not on what the current spec (doesn't) say.


  Cheers,

  Ronald

Received on Friday, 9 October 1998 01:05:21 UTC