On Thu, 16 Oct 2003, Robert Collins wrote:
On Thu, 2003-10-16 at 08:40, Alex Rousskov wrote:
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).
I think its a necessary condition.
OK. Looks like we have consensus on the above. Martin, please add to
HTTP draft. I will try to add an OCP Core requirement for all OCP
bindings to address the problem so that other bindings do not miss the
issue.
Perhaps the only realistic default for a processor would be to
remove Content-MD5 header: absence of truth is better than lies.
For rfc2617/digest signed message bodies and similar mechanisms, it's
probably intractable.
Agreed. If an OPES system is adapting a securely signed message
without access to private keys, that OPES system is misconfigured or
is not authorized to do adaptations. In either case, secure signatures
will work well as long as the client checks for their presence and
validity (assuming they are essential).
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.
Agreed.
Alex.