Re: domain attribute in digest auth/efficiency

> > > The second change you propose is incompatible with RFC 2069, for which
> > > implementations exist. Furthermore, it reduces efficiency. For Basic,
> > 
> > I guess we disagree on the efficency issue (I know for the apache module
> > I've been working on this'll mean usually sending extra bytes over the
> > wire at the same number of RTs).
> 
> Why? I think the typical case will be no domain= at all, and the protection
> domain is the whole server, regardless of the initial URL that you fetched
> from the server.

Only if the server's pages are all in a single protection space (i.e.
realm) and none of them are unprotected ("public"). If any of these two
conditions are not met you'll be sending more bytes over the wire witht
the current default.

Most sites I've encountered which require authorization have some public
pages (i.e. no protection) and some private pages (i.e. protected). Now,
if you don't send domain=... then the browser will send the
Authorization header on all requests, i.e. even for the public pages. 
Because the Authorization header is typically quite large (> 200 bytes)
you therefore are better off sending the domain=... attribute (this
assumes that the private pages all have a common path prefix, but that
is also usually the case because of the way protection is configured).

The situation is similar for multiple realms on a server - the browser
will be sending the Authorization header unneccessarily each time it hits
a new realm.

Now take a server like Apache where .htaccess files can (and do) control
the authorization stuff and can appear in any directory, and then you
see that in general you (the server) don't even have a clue of how many
different realms are on the server and which pages are protected and which
aren't (until you try to fetch them, that is). Therefore you want to send
the domain attribute where possible. (Just for the curious: this isn't
easy to do because the protection is often defined in terms of files or
directories, but the URI-to-filename translation is not always
straightforward (think mod-rewrite)).


  Cheers,

  Ronald

Received on Sunday, 4 October 1998 00:14:21 UTC