RE: context data for squid ICAP patched

Hi Christos,

Thank you for your help, but you suggestion is not secure nor best
perform, Please read my other remarks below.

Now that I read the question again I see it is not clear enough,
I will ask again.
I would like squid ICAP client to do the logic for couple of reasons,
1. Security - Origin sever might change the replied http header and add
the "X-MY-SCANNER: Allow" it self,
                and bypass the content filter, In that case I would not
be able to prevent kids from viewing un honest pages :-(
2. Performance - Redundant call since I already know that request is
allowed.

There for I would like to keep in squids session data the classification
and upon to the classification prior to response-mod call.

For now I have figured out that the best place to set the data between
the req-mod and resp-mod if in the
fde structure, but since squid saves that object in fd_table (hash?)
keyed by ICAP FD there is no continuity with the HTTP FD.
I realized that I need to look for the mechanism that changes the next
handler (hdl) that switch FD to read from, is the KEY to set
up the fde related to the HTTP response, with the classification
information.
In squid ICAP client implementation there is no connection between the
FD sets, ICAP's and HTTP's.

Again 10X for reading and good will,
I hope there is a short cut out there,
If someone has an implementation suggestion or realizes I am missing
something please write me.

>
> Hi Beeri,
> Maybe you do not need to modify the squid-ICAP code to
> support your model.
> I think that the correct implementation of your problem using
> squid-ICAP
> is:
>
> 1) An http request come into the squid. Squid sends the
> reqmod request to the ICAP server and server classifies the request:
> a) In the case of the BLOCK ICAP server creates a http
> response saying
> to the web client that the request blocked
> b) In the case of UNKNOWN ICAP server does nothing
> c) In the case of ALLOW ICAP server adds a proprietary http header
> to the http request for example "X-MY-SCANNER: Allow"
>
> 2) When squid has the http response then sends a respmod
> request to the
> ICAP server. The respmod request contains the http response
> headers AND the http request headers.
> a) When ICAP server founds the "X-MY-SCANNER: Allow" header
> in http request headers it responds with an allow204
> response to
> squid
> b)The "X-MY-SCANNER: Allow" is not in the http request headers
> so the ICAP server takes the http body from squid and
> check it or
> modify it or what else.
>
>
> An other solutions is to use only the respmod request because
> here you have both the http request headers and the http response.
>
> > The Question:
> >
> > I would like to pass the information that, no call to response mode
> > (call the ICAP Server for the response) is needed.
> > ...................
>
> I am not sure that I fully understand your question, but I
> think that this functionality can not included in a general
> ICAP client of squid.
> But maybe I am loosing something here.....
>
> Regards,
> Christos
>
> > Background information:
> >
> > I am implementing an extension to squid ICAP client based upon ICAP
> > Patch and squid 2.5 STABLE 10.
> > The squid ICAP client does not support Content Filtering
> the way we at
> > PureSight.com using it.
> > The ICAP protocol is defined to support also Content Filtering and
> > defines a return value at the request mod stage.
> > I receive the value that can be one of the following:
> > ALLOW,
> > BLOCK,
> > UNKNOWN
> >
> >
> > ..............................
>
>
>
> >
>
>
Received on Mon May 29 2006 - 08:38:27 MDT