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

> >     The term "protection space" gets used without a definition (here),
> >     but the spec. describes how a client can reuse credentials for such
> >     a protection space.  I think we should say that the description of
> >     any auth-scheme must describe the rules for deciding when two
> >     objects are in the same protection space.  In particular, a client
> >     must be able to tell, so it knows whether or not to send credentials
> >     unprompted.
> > 
> Why does it need to tell? If it's wrong, by either sending incorrect ones or
> not sending any, it'll get a 401 to tell it what to do. As far as I can see,
> for Digest it's only an optimization. (For Basic, you don't want to send
> your credentials to the wrong place...)
> > Sect. 3.2.1, The WWW-Authenticate Response Header
> >     [domain attribute]
> >     If this keyword is omitted or empty, the client should assume that
> >     the domain consists of all URIs on the responding server.
> > 
> >       This behavior is different from Basic.  If we want Digest to be
> >       a more or less drop-in replacement, shouldn't the default
> >       behavior mimic Basic?
> > 
> As you point out below, there are implementations. As I point out above, it
> shouldn't matter. If I were writing a browser, I'd guess that I should reuse
> the key obtained from a previous 401/WWW-Auth until I left the server --
> that way, I minimize the extra roundtrips.

There is a certain tradeoff here. Sending the Authorization header with
Digest credentials unnecessarily is not to be shrugged off too lightly,
IMHO - this header is large and can easily double the number of bytes in
a request! (The example in the draft is typical and is 261 bytes).
Certainly, extra roundtrips are to be avoided, but not at all costs.
Also, sending the Authorization header unnecessarily is likely to reduce
the cachability of many pages, thereby further increasing the traffic
(how many responses currently contain the cache-control directive s-maxage
or public? How quickly will this change?).

I'm not really that comfortable with preemptively sending the
Authorization header with *all* requests to a server for which at least
one document needed authorization. I do prefer the heuristic used for
the Basic scheme as I believe it reflects reality much better (i.e.
usually it's just certain url prefixes which require authorization).



Received on Friday, 27 March 1998 02:50:12 UTC