W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

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

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 27 Mar 1998 11:16:25 -0800
Message-Id: <5CEA8663F24DD111A96100805FFE6587031E3C8D@red-msg-51.dns.microsoft.com>
To: "HTTP-WG@cuckoo.hpl.hp.com" <http-wg@cuckoo.hpl.hp.com>, "'Ronald.Tschalaer@psi.ch'" <Ronald.Tschalaer@psi.ch>


> ----------
> 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
Received on Friday, 27 March 1998 11:22:55 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:14 EDT