W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1998

RE: domain attribute in digest auth

From: Paul Leach <paulle@microsoft.com>
Date: Tue, 29 Sep 1998 12:52:20 -0700
Message-Id: <CB6657D3A5E0D111A97700805FFE65875D7761@RED-MSG-51>
To: "'Ronald.Tschalaer@psi.ch'" <Ronald.Tschalaer@psi.ch>, HTTP-WG@hplb.hpl.hp.com, "Jim Gettys (E-mail)" <jg@w3.org>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/65
The second change you propose is incompatible with RFC 2069, for which
implementations exist. Furthermore, it reduces efficiency. For Basic, it had
to be that way because it is very dangerous to send a cleartext password
outside the protection space (inside, too, but that's a different story :-).
For Digest, it is relatively safe to send an Authorization header with a
Digest response to any site that already has seen it, and only get a 401 if
it doesn't work. So, the choice was by design. A server that wants the
"prefix" behavior you propose can respond to "GET http://host/path" with

The first change is backwards compatible, so could probably be made at this
point if there were  concensus. I actually think that one could say that
it's safe to consider all proxies in the same protection space, regardless
of what "domain" says. One shouldn't configure one's browser to point at
proxies to which one wouldn't be willing to send a Digest response. AS a
result, one could almost consider this an implementation issue: clients that
want to pre-authentication to all proxies should just do so.

Jim -- are there any implementations of Proxy-Auth with Digest in the
implementation reports?
Received on Tuesday, 29 September 1998 12:55:17 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:05 UTC