On Wed, 15 Oct 2003, The Purple Streak, Hilarie Orman wrote:
This is the tip of the integrity iceberg. If the point of the
Content-MD5 header is to ensure end-to-end integrity, then it cannot
be modified by intermediaries (even though it would generally but
pretty cheap to do so). It would be more appropriate to add an
OPES-Integrity header with a checksum.
If the Content-MD5 header means "integrity from the last hop that
modified the data, so you can see that there are no transmission
errors", then modifying it is no big deal.
What does the community think it means?
From HTTP point of view, Content-MD5 header is an end-to-end header.
There can be no questions about that. The true question is: what an
"end" means in the context where content is produced dynamically or in
stages, like what we have with OPES.
IMO, from content (and Content-MD5) point of view, an OPES proxy doing
content modification is not an intermediary or a hop, but an "end" or
an "edge" so "content integrity" arguments simply do not apply. From
content consumer point of view, there is no integral content "behind"
an OPES system; content starts after OPES has done its job. That's
what Content-MD5 should represent.
OPES adaptations have to be authorized by content provider and traced
by others, of course, but that is irrelevant to HTTP or OCP issues
being raised in this thread.
We already agreed that OPES proxies can change content. Thus, we have
to give OPES the right to modify or delete content checksums or the
whole architecture would make no sense!
Alex.
P.S. Note that HTTP itself allows for similar modifications that
some might mistakenly call "end-to-end" violations. For example,
HTTP allows for aggregation and anonymization of Via: values.
Such actions are HTTP-equivalent of OPES adjustment of
Content-MD5 values.