- From: Patrick McManus <mcmanus@appliedtheory.com>
- Date: Fri, 24 Jul 1998 14:05:29 -0400 (EDT)
- To: http working group <http-wg@cuckoo.hpl.hp.com>
This is a message I've been meaning to send for a while, but other
projects have a way of getting in the way.. I apologize for a certain
lack of precision that will follow, but I wanted to raise the issue.
Ronald and I did a bit of interoperability testing wrt Digest
Authentication.. and we discovered what might be a problem (From the
auth draft)
:: 4.6 Weakness Created by Multiple Authentication Schemes
::
:: An HTTP/1.1 server may return multiple challenges with a 401
:: (Authenticate) response, and each challenge may use a different scheme.
:: The order of the challenges returned to the user agent is the order that
:: the server would prefer they be chosen. The server should order its
:: challenges with the "most secure" authentication scheme first. A user
:: agent should choose to use the first challenge it understands and
:: request credentials from the user based upon that challenge.
::
My problem is that if my server doesn't list Basic as the first choice
(but does list is as less preferred to Digest) some existing 1.0 clients
that can't do digest but can do basic don't realize that basic is an
option.. and if I do list basic first then I am suggesting to clients
(as per 4.6) that I want that more than digest, which is definitely
not the case.
(basic,digest) (digest, basic)
lynx 2.8.1 dev 17(and prev) Y N
netscape 4.05 Y Y
msie 4 Y N
Y = interoperable
(netscape has some strange behavior.. it will send basic responses no
matter the challenge type... even if only digest!)
I'm generally in favor of 1 of two paths to resolve the issue:
1] remove the notion of server specified preference.. the
credentials belong to the client, it seems to me they should
understand what the risks are in sending them out on the
network. In this way the challenge specifes understandable
methods only.
2] introduce q values
thoughts?
-P
Received on Friday, 24 July 1998 11:06:36 UTC