ietf-openproxy
[Top] [All Lists]

Re: OPES ARCHITECTURE

2001-02-13 15:32:51
  I think , there should be only modification of headers and no addition.If 
rule
base is based on N headers , then property set should contain all those N
headers . If that header value couldn't be obtained from message , then that 
can
be considered as NULL , which can be later modified .

Services/proxylets should not be restricted to the modification of
message headers. With proper authorization, service modules/proxylets
should also be allowed to add and remove message headers. An
anonymization service, for example, may want to remove a cookie header. 

  Issue regarding ICAP service call .

  Modification of header values in case of local proxlets can be done using
library functions and hence property set can be modified  reliably . But in 
case
of ICAP service calls , there should be some way of informing the OPES
environment , that few properties can be modified .Can we provide this
information in Rule File ( XML file ) along with the "action" field .

Both the local and remote service execution environment should have the
same standardized interface through which service modules can add,
modify, and delete message properties or the message body. From a
service modules's point of view, it should not make a difference whether
it is executed on a remote callout server or the caching proxy itself.

Such a standardized interface can then be used by local service modules
to directly manipulate the message context on the caching proxy which
holds request/response message properties/bodies of the current
transaction. The message context is also queried by the rule engine
whenever rule conditions are matched.

In the case of remote service modules, however, service modules cannot
directly access the message context on the caching proxy. Instead, a
remote callout protocol like ICAP is necessary to return the message
property modifications to the caching proxy.

So in the case of ICAP, the ICAP server sends the modified message to
the ICAP client on the caching proxy. The ICAP client then parses the
ICAP response and updates the message context on the caching proxy
accordingly. Subsequent rules can then be matched against current
property values.

-Andre