Digest protection spaces

rfc2617, section 3.2.1, when describing the domain directive for a 
digest-challenge says, "The client can use this list to determine the 
set of URIs for which the same authentication information may be sent: 
any URI that has a URI in this list as a prefix (after both have been 
made absolute) may be assumed to be in the same protection space. If 
this directive is omitted or its value is empty, the client should 
assume that the protection space consists of all URIs on the responding 
server."

Does this mean that if a server has multiple protection spaces, they 
cannot be nested? For example, if a server had a hierarchy of abs_paths 
like this:

"/Users"
|_____________
|             |
"/Users/Bob"  "/Users/Public"
|
"/Users/Bob/Pictures"

Can "/Users" be in one protection space, and "/Users/Bob" be in another 
protection space?

One implementation I've seen assumes the protection space for "/Users" 
includes "/Users", "/Users/Bob", "/Users/Public" and 
"/Users/Bob/Pictures", and that accessing anything below "/Users" with 
those credentials won't generate a challenge unless the server wants to 
update the credentials for that protection space.

Another implementation I've seen assumes "/Users/Bob" can be in a 
different protection space than "/Users". For example, if 
authentication credentials are known for both "/Users" and 
"/Users/Bob", the "/Users" credentials could be used for "/Users" and 
"/Users/Public" while the "/Users/Bob" credentials must be used for 
"/Users/Bob" and "/Users/Bob/Pictures" (i.e., the "/Users" credentials 
won't work for "/Users/Bob" and "/Users/Bob/Pictures").

Which implementation is correct?

Jim Luther

Received on Tuesday, 6 May 2003 20:04:34 UTC