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

authentication-02: use of digest-uri

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Thu, 20 Aug 1998 15:16:13 -0400 (EDT)
Message-Id: <199808201916.PAA25787@aleatory.research.bell-labs.com>
To: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/346

    The authenticating server must assure that the document
    designated by the "uri" parameter is the same as the document
    served. The purpose of duplicating information from the request
    URL in this field is to deal with the possibility that an
    intermediate proxy may alter the client's request. This altered
    (but presumably semantically equivalent) request would not result
    in the same digest as that calculated by the client.

Let's say the URL is "http://example.com/foobar".  digest-uri-value
can be any HTTP/1.1 request-uri.  Should the client set uri="/foobar"
or uri="http://example.com/foobar"?  Does the answer depend on whether
the client connects to example.com through a proxy.  (I hope not.)

An HTTP/1.1 server at example.com can legitimately get either of these
request lines:
	GET /foobar HTTP/1.1
or	GET http://example.com/foobar HTTP/1.1

(An HTTP/1.1 proxy could, for example, pass the second line to the
origin server.)

The origin server is supposed to compare the digest-uri-value and the
request-uri.  It could thus find itself comparing the abs_path and
absoluteURI forms, one from uri=, the other from reguest-uri.  At the
very least, I think the spec. should alert implementors to that

(And I assume the correct behavior is to respond with 400 Bad Request
if there's a mismatch.)

Dave Kristol
Received on Thursday, 20 August 1998 12:19:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:23 UTC