On Thu, 2003-10-16 at 08:40, Alex Rousskov wrote:
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?
I think its a necessary condition.
Agreed.
Perhaps the only realistic
default for a processor would be to remove Content-MD5
header: absence
of truth is better than lies.
For Content-Length adaptation we will use the sizep value.
It seems to be an overkill to add more values for other headers.
So, removing of those headers such as Content-MD5 is the only choice, unless
- OPES processor collects all data until the end and recalucates the
value if possible/capable
- callout services responds with DUY message(s) that the message did not
change
For rfc2617/digest signed message bodies and similar mechanisms, it's
probably intractable.
For non verifiable headers - I think it depends on the advertisied
origin: that is if the OPES device is comparable to a reverse
proxy, it
is considered authoritative for the entity and can safely correct such
headers. For non authoritative OPES devices - say ISP's
performing local
ad replacement (ignoring the policy questions surrounding that) - then
removing it is probably the most accurate step.
I like the example of the reverse proxy that may even deploy an OPES callout
service to calculate the
MD5 checksum. In this case, the header will be introduced by the callout
service. If the OPES processor
trusts that service, it can leave it in (still being responsible for the
correctness).
Question is now: Is this trustability something which is defined outside of
OCP? Or do we after all need
a way to signal "I, the callout service, checked/modified/added this header and
say it is good so, please
trust me and use it when forwarding on the HTTP path"
And is it so simple to talk about all headers that start with "Content-". Are
all of those and only those affected?
I don't think so.
- Content-Encoding we already discussed, it's different
- Changin the Content-Language is nothing that happens accidentally as MD5
checksum changes.
If a callout service does language translation, it should also adapt this
header field.
I don't know how an OPES processor could recalculate this easily. Language
changes are
very exceptional, always deleting the header seems to be an overkill
- Content-Type is the same as Content-Language I believe.
Regards
Martin