- From: Paul Leach <paulle@microsoft.com>
- Date: Thu, 29 Feb 96 09:34:44 PST
- To: http-wg-request%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy says: ] ] > <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 ] ] That won't work. HTTP header fields of the same name can be appended ] together, and header fields of different names can be reordered, by ] any HTTP recipient without changing the semantics of the message. ] The only way to digest the header fields is to first encapsulate them ] using something like WRAPPED or MOSS. Is there something wrong with saying that if authentication is desired, then the digest must be computed by the recipient before such transformations are made? After that, it can do what it wishes, reordering, etc. wise. In order to authenticate, _some_ canonical form is needed, but _any_ one will work; some are less convenient than others. I chose the one in the proposal because it seemed like the least work for both sender and receiver. Note: <header-digest> is a hop-by-hop authentication mechanism, so the issue of proxies wanting to do the transformations you describe is not present. If it were, I'd agree with you that it was an unreasonable burden on the proxy to remember exactly how the origin-server sent the headers and resend them to clients unmodified. Paul
Received on Thursday, 29 February 1996 09:31:49 UTC