- 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