ietf-openproxy
[Top] [All Lists]

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

2003-10-16 09:12:50


On Thu, 16 Oct 2003, Martin Stecher wrote:

For Content-Length adaptation we will use the sizep value.
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.

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

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.