I think Cache-Control headers and related response codes should be applied
exactly to the subject they claim - cache control. The extended use of HTTP
as a base protocol results in temptation to overload semantics of existing
headers. Mark Nottingham pointed one example of such overload about a year
ago (forgive me if I'm wrong with dates). Mark has posted a document
explaining why use of cache control headers is bad in origin-surrogate
context: semantic roles of HTTP client and server are different from the
surrogate-origin server case - they have a special trust relationship, and
cache control part of HTTP should better be preserved to manage downstream
caches.
The same approach should be taken for the callout protocol. The proxy that
is running OPES rules serves as a callout gateway. According to the OPES
intentions and IAB guidelines it has an explicit permission to perform
certain actions - that is, special relationship with either origin server or
the end user. Cache control directives should be preserved for caches that
may occur between OPES gateway and end user - otherwise there is no
mechanism left for content producer to control intimidate cache behavior.
Callout participants and callout protocol SHOULD NOT try to interpret such
directives.
One additional implication is that in some scenarios OPES server (and
implicitly OPES gateway) may act as an authorized surrogate content
producer. In this scenario cache control directives MAY by altered to
reflect the changed content semantics. The way to handle them was very well
described in Mark's document mentioned above. I do not remember what
happened to it, I'm afraid it just expired as a draft. Again, sorry if I'm
wrong. Mark MAY shed more light on the fate of this document.
- Oskar
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of
Markus Hofmann
Sent: Tuesday, April 16, 2002 2:34 PM
To: Mark Nottingham
Cc: ietf-openproxy(_at_)imc(_dot_)org; LMM(_at_)acm(_dot_)org
Subject: Re: no-transform & Warning
Mark Nottingham wrote:
I was talking about placing a requirement on the OPES server
implmentation, not the callout protocol itself. I.e., the protocol can
be agnostic, but the thing that stuffs HTTP messages into it had better
understand the semantics of HTTP.
Yup, this I agree with, building the application semantic around a
generic protocol, rather than building it into the protocol itself. It
was not clear to me whether people thought of making the callout
protocol itself aware of the encapsulated application protocol.
-Markus