Re: icap devel branch feedback

Robert,

.. stripped ....
> Multiple req/resp mods at a particular location *can* be done via a
> intermediate iCAP server, but is that a good idea? IIRC the ietf
> open-proxy list has recently taken such chaining servers out of the
> policy document... Not that this is a big issue either way, just it
> might be simpler for the user if they can configure it either way.

Our implementation of the ICAP framework on sourceforge is slightly
different. It *includes* an IRML parser on the server-side and hence the
rules can be set up in such a way that multiple rules match and hence
multiple services get executed at the same icap server. The decision of
the open-proxy list to defer requiremnt for chaining servers is mainly
todo with chaining icap services in different icap servers - as I
understand. The opes achitecture proposes the rule engine in the
intermediary.
The new configuration syntax we have added to squid (for icap) does
allow specification of multiple icap servers at every vectoring point.
http://icap-server.sourceforge.net/squid.html It is just that we now
take only the first match.
The configuration syntax is described at
http://icap-server.sourceforge.net/icap-configuration.html and is the
contribution of Ralf Horstmann from Web Washer. Let us know if you have
any feedback on that.
In a related question, do you see squid supporting IRML in the long run?
Most of it is already available in the form of config statements - it
simply will change to be an XML way of stating things.

> ....There are HTTP parsing routines in Http*.c (Note the Capital) that do
> all the work. Anything in http.c that you *need* is likely a hangover
> from waay back. Let me/us know if you encounter such code, I'd like to
> ensure that http.c itself leverages common code as much as possible.
> http.c in fact is a misleading name. It's better described as 'squid's
> builtin http client'
That's rigtht. Hopefully all those dependencies will disappear when icap
client fits into the content filter/esi patch.

regards
Geetha
Received on Mon Aug 19 2002 - 22:29:00 MDT