> ----------
> From: Ronald.Tschalaer@psi.ch[SMTP:Ronald.Tschalaer@psi.ch]
> Sent: Friday, March 27, 1998 1:45 AM
> To: HTTP-WG@cuckoo.hpl.hp.com
> Subject: 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.
>
I agree.
> 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.
>
For Digest, the choice is just a heuristic. For Basic, if you guess wrong,
you've given your password away.
> 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?).
>
It is worth adding a note that origin servers that receive requests with
Authorization headers when authorization is not needed SHOULD send back
explicit cache-control directives to allow the page to be cached.
> 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).
>
I'll look at some wording to make it clear that for digest, the domain space
is just advisory, but with the implications noted above.
Paul