> ---------- > 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. PaulReceived on Friday, 27 March 1998 11:22:55 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC