W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 1998

Re: More comments on draft-ietf-http-authentication-01.txt

From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
Date: Thu, 9 Apr 1998 02:53:59 +0200
Message-Id: <98040902535975@psicla.psi.ch>
To: GISLE@aas.no, HTTP-WG@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/33

> Ronald.Tschalaer@psi.ch (Life is hard... and then you die.) writes:
> 
> > > 2) How to interpret the URIs in the 'domain' attribute of the Digest
> > > WWW-Authenticate is not clear to me either.  Are the URIs in this
> > > list path prefixes that define protection spaces or must there be
> > > an exact match.  If it is a prefix, what happens if the URI contains a
> > > query part.
> > 
> > An exact match.
> 
> Would not that make this attribute too long to be useful for any real
> use?  If you try to protect one specific server script you have to
> make a domain attribute that lists all possible parameters (query
> part) that this script takes.

Either that, or hope the client does some intelligent guessing. Though
I don't think that the situation is that bad. I'd expect most clients
to note the new protection spaces (i.e. the tuples (host, port, scheme,
realm) ) in any case, so that at worst you get a needless round-trip for
the 401; but at least the user won't be prompted for the username/password
again (which I believe is the main reason for the domain attribute).

> This also brings up another question on how nonce-count and domain
> interact.  If you have a Digest space that spans several servers,
> should the nonce-count be incremented seperately for these servers or
> should they share it?

I've assumed a nonce per protection space (i.e. separate nonces and
nonce-counts above). However, I can't find anything specific in the
spec, so I believe this should be clarified too.


  Cheers,

  Ronald
Received on Wednesday, 8 April 1998 17:56:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:05 UTC