[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    context data for squid ICAP patched
From:       "Moshe Beeri" <Moshe.B () puresight ! com>
Date:       2006-05-31 15:03:56
Message-ID: DFB224C4B320AE4E8508B1B1DF075A200102EDDE () mail1 ! icognito ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]