Altering the cache control header will work, but it could lead to side
effects.
If you take the case when service's clients are subnetworks or enterprises
with proxies on it, they wont be able to cache the response any more.
In the same way, client application can respect too closely zero TTL and
re-send request very frequently.
Result will then be an increased load on your processor, and the benefits
of caching unfiltered content will be loss.
But you're right, the problem is specific to some application protocols
(and also some cases), so it can be address in application bindings.
Karel
De : Alex Rousskov
Envoyé : mardi 26 août 2003 17:06
À : MITTIG Karel FTRD/DMI/CAE
Cc : ietf-openproxy(_at_)imc(_dot_)org
Objet : Re: RE : draft-ietf-opes-ocp-core
I agree that cache control is a desirable feature in many
environments. There are several related observations:
- Some application protocols to not support the
notion of caching (e.g., SMTP).
- Application protocols that support caching
usually have built-in caching controls (e.g.,
Cache-Control header in HTTP). These controls
are often quite sophisticated.
It looks to me that adding cache control features to OCP Core
would be wrong because some protocols do not have a notion of
caching at all, and those protocols that do already have
extensive controls that OCP Core would not be able to
duplicate in a generic manner.
How about this:
- Let OCP application bindings handle cache control
issue.
- Recommend that an application binding relies
on existing application controls rather than
extend OCP.
Would that address your needs, including the filtering
example you gave above? Can the filter service alter
Cache-Control headers of the filtered responses appropriately?
Thanks,
Alex.