Hi all squiders,
I found the right way to implement the content filter extention to
squid.
I will continue the implementation and will send it to our QA Team,
I hope the whole squid community will use this extention to squids ICAP
capabilities.
Best regards,
Moshe Beeri.
Software Engineer, Server Team.
Moshe.B@PureSight.com
Petach-Tiqva Bazel 16, Israel.
Tel: +972 (3) 928-0400 ext. 429
Fax: +972 (3) 921-7594
>
> 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 Wed May 31 2006 - 09:03:40 MDT
This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:04 MDT