Re: icap devel branch feedback

On Mon, 2002-08-19 at 16:51, Geetha Manjunath wrote:
>
> Hello Robert,
> Sorry for this delayed reply.. took off - an early weekend:-)

Not a problem - there is no rush.
 
> Thanks for going through the icap branch.. One quick comment is that the
> sources on that branch are not current. We keep the CVS current only at
> http://sf.net/projects/icap-server. Sorry about that. I wanted to update
> the sources here too - but did not find time for performing the HEAD
> update and testing it out again... Will try to do so shortly.

I'll be happy to have another look as you push your changes through to
the squid CVS repository.
 
> The version on the icap-server sourceforge project supports both reqmod
> and respmod. However, out the four possible vectoring points (pre cache
> reqmod, post cache reqmod, precache respmod and postcache respmod), the
> precache respmod is not supported, and pre cache reqmod is not yet fully
> tested (available as a patch only). Multiple reqmod's and multiple
> response modifications at a particular vectoring point can be supported
> in the icap server side. The example you mentioned requires support for
> content modification at all VPs - will be there in one of the future
> releases ;-)
   
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.

> Yes. I should do that sometime. Infact I did start that way - plugging
> things in as callbacks - but faced a lot of problems. Let me check out
> after your changes are into the HEAD.
> However, I may still need to use some of the functions in http.c as the
> encapsulated messages are all HTTP .. instead of rewriting the HTTP
> header parsing routines, i thought i could as well leverage.

Yep :}. I've actually implemented all four VP's in an older project -
the content modification project, which was a framework designed to make
things like iCAP easier to implement. If you have trouble, feel free to
discuss it here - I know some of the tricks }:. That project is on hold
due to lack of time (and some very pervasive architecture problems in
squid < HEAD), not interest.

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'.

Cheers,
Rob