ietf-openproxy
[Top] [All Lists]

Re: PSRL: A Rule Specification Language for Proxy Services

2000-11-29 23:24:31

Date: Wed, 29 Nov 2000 19:43:34 -0500
From: Andre Beck <abeck(_at_)bell-labs(_dot_)com>
 Consider this case: based on some property values,
some rules are matching, say the first of such rules
is triggered. Now suppose the proxylet associated with
the triggered rule changes some of the property
values, which now match some other rules, so they may
be triggered. And this may go on. To check which new
rules are triggered the message (body and header) may
have to be parsed again.Isn't there a chance of cyclic
rule triggerring? Means after a series of rule
triggering and property value modification, the first
rule may be triggered again.

All the rules in a rule module are processed in the order they are
specified in the rule module. Each rule gets processed only once
regardless of whether it matches or not. If a rule matches, the
appropriate action is executed, but this particular rule or any other
rules that have already been processed will not be processed again. This
is why the rule ordering is so important. Cyclic rule triggering should
therefore not be possible. 

        If there is some content modification (modification
in the message body itself), then in that case, the
complete message body has to be parsed again, to find
out what new rules can match based on the current
property values. Is this feasible?

I agree that the approach to match rule properties against current
property values is less efficient than to always match against the
original value, but I don't think it's necessary to parse the message
more than once, at least not for local proxylets that can use proxy
library functions to modify certain property values.

It may not be possible (or advisable) to avoid parsing the message more
than once if we allow rule match against current property values. It
can be cumbersome when content modification is allowed, but no doubt
can be done more efficiently if we allow local proxylets to modify
contents only through library calls.

In the case of ICAP
services, however, it will be necessary, to parse the ICAP response
every time an ICAP transaction is performed.

        A suggestion is that to have a field( or element)
"Could Modify" in the rule which will tell which
property values it MAY change. This may atleast tell
which rules are mutually exclusive and won't need
separate parsing of the message for those rules
atleast.

This could improve the performance of the rule processing engine on the
caching proxy, but on the other hand since rule authors may not be the
identical with the authors of service code modules it may be difficult
to always keep the rules consistent with the service modules.


We could have the "could-modify", "could-add" kind of properties be
associated with the service module. This would help the rule authors understand
better what they may be getting into and will also help the performance of
the rule processing engine. If we can have ICAP services return (optionally)
a "have-modified" header as the first header, that would also improve
the rule processing tremendously. (This header would need to be stripped off
by the proxy and hence should be sent only if the proxy has indicated
that it can handle it)

Sherif

-Andre