RE: Proposal for new HTTP 1.1 authentication scheme

On Mon, 8 Dec 1997, Paul Leach wrote:

> I think that the spec for "domain" is broken -- it specifies a list of URIs,
> but doesn't say that these can be _prefixes_ of URIs that may also use the
> same credentials. Without that, it is pretty uselss, IMHO.

Actually my guess is that this is what's happening already implicitly (it's
how I've implemented it): if you take the paragraph from the authentication
spec

     A client SHOULD assume that all paths at or deeper than the depth of the
     last symbolic element in the path field of the Request-URI also are
     within the protection space specified by the Basic realm value of the
     current challenge. A client MAY send the corresponding Authorization
     header with requests for resources in that space without receipt of
     another challenge from the server.

and apply it to Digest then you're effectively assuming all URIs to be
prefixes.

Is there a specific reason this shouldn't be done? My feeling was (and
looking at the digest implementation in a certain well known server seems
to confirm this) that people will use digest as a drop in replacement for
basic authentication, and hence the rules for pre-emptively sending auth
info should be the same for both schemes.

In a similar vein, I've never really understood the motivation for the
last sentence in:

     domain
       A space-separated list of URIs, as specified in RFC XURI [7]. The
       intent is that the client could use this information to know the set
       of URIs for which the same authentication information should be sent.
       The URIs in this list may exist on different servers. If this keyword
       is omitted or empty, the client should assume that the domain
       consists of all URIs on the responding server.

It seems a little overeager to me. I'd say drop it completely (assuming
the application of the first quoted paragraph to digest) or replace it
with something like

     domain
       A space-separated list of URIs, as specified in RFC XURI [7]. The
       intent is that the client could use this information to know the set
       of URIs for which the same authentication information should be sent.
       The URIs in this list may exist on different servers. If this keyword
       is omitted or empty, the client should assume that the domain
       consists of all URIs on the responding server with paths at or deeper
       than the depth of the last symbolic element in the path field of the
       Request-URI.


  Cheers,

  Ronald

Received on Thursday, 11 December 1997 15:19:20 UTC