Subject: RE: HTTP/OCP: All Content-* headers are special

From: "Martin Stecher" <[email-masked]>
Date: Thu, 16 Oct 2003 14:48:28 +0200

> 
> 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

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 16 Oct 2003 10:12:49 -0600 (MDT)

> It seems to be an overkill to add more values for other headers.

Or nearly impossible, as the case with Content-MD5 is. A service that
modifies content is very unlikely to be able to compute new MD5 in
advance.

>       - callout services responds with DUY message(s) that the message did not change

Agreed (the latter condition assumes that processor trusts the service
enough to risk its own [in]compliance on service behavior).

> 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).

Agreed.

> 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"

I think we tried to do this in the past and failed. I suggest that
this kind of statements are outside of our scope. In most cases,
processors will know what services they deal with and can be
configured to [not] trust them accordingly, on a case-by-case basis
with "do not trust" as the default.

Perhaps we should make that default more clear in the specs.

I hope your [very valid] Content-Language concerns below can be
addressed without adding "trust me with this header" interface.

> 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.

Good point.

>  - 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-MD5 computation is clearly documented. Content-Language is not
a computable setting so OPES processor cannot verify or "fix" it.
Perhaps our rules should be more precise to exclude non-computable
headers?

>  - Content-Type is the same as Content-Language I believe.

Yes.

Alex.