- From: Daniel DuBois <dan@spyglass.com>
- Date: Fri, 13 Dec 1996 16:37:30 -0800
- To: paulle@microsoft.com
- Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, pmontelo@spyglass.com
At 04:18 PM 12/13/96 -0800, Paul Leach wrote:
>Imagine that you've computed an MD5 (or other) checksum over the content
>body and various of the headers. If you change any of them, the digest
>won't check thereafter. When the digest is used for authentication and
>as a secure integrity check, the failure of the digest to check would
>lead to some kind of security fault. The "no-transform" directive was
>added to tell proxies that changing the body or certain headers would
>lead to some kind of failure.
>
>In the case in question (an HTTP to mail gateway), it may not be
>important that the recipient of the Mime-body be able to verify its
First let me say I'm not concerned with mail gateways, so I don't want to
get too lost thinking about the implications of such. :)
I understand what you are saying in the first paragraph, and it sounds like
what you are saying applies to Transfer-Encoding as well. Or are we
presuming that whatever the digest-computation algorithms are in the browser
(and the server as well!) they are both intelligent/aware enough to ignore
the Transfer-Encoding headers in their computations?
If we can't make that assumption (it sounds like a tenuous one), then we
should state somewhere in the HTTP/1.1 spec that proxies are *not* allowed
to remove Transform-Encodings on responses/messages that have a no-transform
Cache-Control directive.
Are there any other implications of this?
Now I think some more about it.... Why are we specifying headers at all?
Why aren't they ALL un-modifiable in face of no-transform and the
possibility of a some-headers-digested situation?
-----
Daniel DuBois, Traveling Coderman www.spyglass.com/~ddubois
o The Heroes of Might and Magic II Bible is here!
http://www.spyglass.com/~ddubois/HOMM2.html
Received on Friday, 13 December 1996 16:41:02 UTC