RE : RE : draft-ietf-opes-ocp-core

["MITTIG Karel FTRD/DMI/CAE" <karel.mittig@xxxxxxxxxxxxxxxxxxxx>]

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