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?
Hilarie
Motivation: We are running some ICAP tests here, and Polygraph is
detecting MD5 checksum errors on messages that went through an HTTP
proxy that uses an ICAP server. Apparently, neither the proxy nor the
ICAP server are adjusting Content-MD5 value when adapting content. I
checked ICAP RFC and did not find references to Content-MD5, only
Content-Length. I suspect an implementor may overlook the dependency
between adapted content and HTTP/MIME checksums if we are not being
more explicit about such dependencies.
I am not sure that Content-MD5 adjustments at the processor can
be cheap, but I think we have to document what the processor has to do
to avoid end-to-end checksum errors. Perhaps the only realistic
default for a processor would be to remove Content-MD5 header: absence
of truth is better than lies.