Re: Draft 01 of HTTP/1.0

On Tue, 20 Dec 1994, Eric W. Sink wrote:
> The following section from Draft 01 seems odd.
> >6.4.2 WWW-Authenticate
> >
> >   The WWW-Authenticate header field must be included as part of the
> >   response if the server sends back a "401 Unauthorized" Status-Code
> >   on a request from the client as part of the Basic Authentication
> >   Scheme described in Section 9. This header field indicates the
> >   authentication scheme in use and the realm in which the requested
> >   URI belongs.
> >
> >       WWW-Authenticate        = "WWW-Authenticate" ":" (
> >                                   ( "Basic" realm )
> >                                 | ( extension-scheme realm ) )
> >
> >       realm                   = "Realm" "=" 1#( "<" URI ">" )
> >
> >   The first word of the field value identifies the authorization
> >   scheme in use and is followed by the realm of the protected URI.
> >   The realm is a comma separated list of URIs, where relative URLs
> >   should be interpreted relative to the URI of the requested resource
> >   in the RequestLine. If a request is authenticated and a realm
> >   specified, the User-ID and password should be valid for all other
> >   requests within this realm.
> >
> >       Note: The realm may span more than one origin server.
> I'm not aware that people generally use the realm as a comma separated
> list of URIs.  I remember hearing someone say at the BOF that it would
> be nice to be able to specify that URIs on other machines can be accessed
> as part of the same realm.  Perhaps this section has been phrased
> accordingly?

Dat waz me :)  The documentation for NCSA's httpd states (in 

"The AuthName directive sets the name of the authorization realm for this
directory. This realm is a name given to users so they know which username
and password to send."

...meaning right now at least this server interprets Realm to just be a
string of characters, a name, that defines the authentication space on a
given host.  I.e. hostname + realm string = authentication realm.  Some
browsers are generous in presuming what other docs might also be under
authentication, for example resending the name and password with every
subsequent access to the same machine, or only to within the same
directory as previously authenticated areas.  The CERN docs
( were
never clear on how the browser should determine ahead of time if a request
should have the authentication info sent along by default, given the
history of which documents needed authentication - the realm string was
all that was supposed to be used.  Some conservative browsers only go by
subdirectory - an authenticated request under /dirone doesn't mean they
should resend the authentication info for an access in /dirtwo, but do so
immediately after getting the 401 message.  This is fine by me, since the 
user still only types his password in once.  Some even more conservative
browsers consider hostname + path + realm string to be the definition of
authentication realm, and thus require reauthentication between different
subdirs on the same host.  This is something I've run into here (our root
level is unprotected but almost all subdirs are), and since the most
common browsers don't require complete reauthentication between
directories and the CERN documentation is vague I don't think I'm in
violation, but this system is clearly a mess. 

If, instead of a string, we specified exactly where (both by hostname and
by path) the password authentication is valid, there's be no ambiguity as
to when the browser automatically resends the authentication information. 

> Was this section written to reflect current practice, or was it written to
> be better than current practice?

The above clearly does not describe current practice, but is definitely 
something I'd like to see in 1.1.  


Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3

Received on Tuesday, 20 December 1994 23:11:05 UTC