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

> ----------
> 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