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.htmlReceived on Friday, 13 December 1996 16:41:02 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC