Rajnish,
Suggestion : We can put such rules at point 3. And rules at point 3 should
be always considered, irrespective of object coming from origin server or
cache.
This would help us in taking advantage of cache.
I think we have to differentiate between services that generate a
user-specific response and those that don't.
User-specific services usually modify Web objects depending on certain
user characteristics, for instance if the user's native language is
German, then all Web pages are translated to German or if the user's Web
access device is a Nokia cell phone, then all requested Web objects are
adapted to fit the screen of the user's Nokia cell phone.
The second category of services modify Web objects equally for all
users. For example, a virus scanning service removes the same viruses
for all users. Or a bandwidth-saving service may compress all Web pages
with gzip before they get sent to the users.
Rules that trigger services of the non-user-specific kind should be
processed at processing-point 3 because the service execution result may
automatically end up in cache if the caching proxy decides that the Web
object is cacheable. These cached objects would subsequently be served
to other users as well.
Rules that trigger user-specific services should be processed at
processing-point 4. The service execution results at point 4 could still
be cached. However, they would be cached by the service itself rather
than by the caching proxy. The same is true for the retrieval of such a
cached Web object. The caching proxy wouldn't know what object to serve
to the client because it doesn't know the user's characteristics like
preferred language etc. Therefore this would probably require a service
at point 1 which gets triggered for certain user requestss and would
then check for a cached Web object that matches the user's
characteristics.
Comments?
-Andre