Martin,
Could you please check that HTTP Adaptations draft talks about
OPES processor responsibility for "correctness" of not just
Content-Length header but all(?) Content- headers including things
like Content-MD5? Perhaps we can include a general statement that
covers all headers?
HTTP OPES processors MUST insure correctness of
all HTTP headers documented in specifications
that the processors intend to be compliant with.
For example, the correctness of Content-Length
and Content-MD5 headers have to be insured by
processors claiming compliance with HTTP/1.1
(RFC 2616).
Or would that be an overkill?
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.
It would still be up to the processor how to "insure correctness". As
discussed earlier, a given processor may have enough reasons to trust
a given service to adjust all headers accordingly. The processor is
judged by the final outcome only, not by the mechanism used to achieve
that outcome.
Sizep tricks will make Content-Length adjustments at the processor
cheap. 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.
Alex.