- From: Paul Leach <paulle@microsoft.com>
- Date: Wed, 28 Feb 96 17:19:46 PST
- To: john@math.nwu.edu
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 28 Feb 1996, John wrote: ] ] Great. But try to do it quickly. I would like to get version 03 of this ] document submitted. Here's a proposal for a replacement for the description of Degest-MessageDigest: HTTP/1.1 200 OK Digest-MessageDigest: message="<message-digest>", header="<header-digest>", response="<response-digest>", nextnonce="<nextnonce>" The Digest-MessageDigest header indicates that the server wants to communicate some information regarding the successful authentication (such as a message digest or a new nonce to be used for the next transaction). <message-digest> is a keyed digest of the entity in the response. It is computed as <message-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" + H(<entity-body>) + ":" + <date>) where A1, N, A2, and <entity-body> are the same as in the algorithm given above for <message-digest> in the Authorization header, and <date> is the value of the Date header in the message containing this header. (In the case of caches, this will be the Date in the original response from the origin-server that contained this <entity-body>.) This allows the client to verify that the body of the response has not been changed en-route, and the freshness of the response (i.e., the client can know the time that the origin server server sent the response, thus preventing caches from claiming responses are newer than they actually are). The server would probably only send this when it has the document and can compute it. The server would probably not bother generating this header for CGI output. <header-digest> is a keyed digest over the entity headers (as defined by HTTP -- e.g., as of HTTP/1.1, Content-Type and other Content-* headers, Last-Modified, Expires, etc.) It is computed as <header-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" + h1 + ":" + h2 + ... + ":" hn + ":" + <date>) where A1, N, A2, and <date> are the same as in the algorithm given above for <message-digest>, and h1 to hn are the entity headers in the response, in the order sent by the origin-server and in the origin-server's case, including, for each header, the header name, the colon, the value of the header with its original LWS, and the trailing CRLF. Similarly to the <message-digest>, this allows the client to verify that the entity headers have not been changed en-route. <response-digest> is a keyed digest over all headers in the response other than the entity headers. It is computed as <response-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" + h1 + ":" + h2 + ... + ":" hn + ":" + <date>) where A1, N, A2, and <date> are the same as in the algorithm given above for <message-digest>, and h1 to hn are the other headers in the response, in the order sent by the server and in the server's case, including, for each header, the header name, the colon, the value of the header with its original LWS, and the trailing CRLF. (In this case, the server could be the origin server or a proxy.) Similarly to the <message-digest>, this allows the client to verify that the response headers have not been changed en-route. <nextnonce> is the nonce the server wishes the client to use for the next authentication response. All fields are optional. In particular the server may send the Digest-MessageDigest header with only the nextnonce=<nextnonce> field as a means of implementing one-time nonces. If the nextnonce field is present the client is strongly encouraged to use it for the next WWW-Authenticate header. Failure of the client to do so may result in a request to re-authenticate from the server with the "stale=TRUE."
Received on Wednesday, 28 February 1996 17:16:58 UTC