RE: HTTP/1.1 Contradiction

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