context data for squid ICAP patched
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. [EMAIL PROTECTED] 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 ..
context data for squid ICAP patched
Hi all squids, 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 So far as described by the ICAP protocol (RFC 3507) and implemented by our ICAP server. As for squid client I added the ability to identify classification value, I would like squid to behave according to that value: 1. In case of UNKNOWN the response should go back to the ICAP server to be reclassified. 2. In case of BLOCK the ICAP server is changing the URL to retrieve a blocking information page. 3. In case of ALLOW squid should reply directly to the client with or without using the cache. 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 would like your help with the way squid saves session data, I look at the code and I could not find that particular object, is there one? Any suggestions || directions would be blessed. The Polite part: Thanks for reading Participating on that grate project of squid. Your help Moshe Beeri. Software Engineer, Servers Team. [EMAIL PROTECTED] Petch-Tiqva Bazel 16, Israel. Tel: +972 (3) 928-0400 ext. 429 Fax: +972 (3) 921-7594
Re: context data for squid ICAP patched
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 clasifies the request: a) In the case of the BLOCK icap server creates a http responce 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 responce then sends a respmod request to the icap server. The respmod request contains the http responce 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 responce 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 becouse here you have both the http request headers and the http responce. 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 ..
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 ..
RE: context data for squid ICAP patched
Hi Beeri, 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 :-( Yes this problem exists. I am just refering it as way to pass info from reqmod to respmod icap services. 2. Performance - Redundant call since I already know that request is allowed. Yes the performance is a problem here. Assuming that you have 95% accepted requests and only 5% blocked maybe is not so problem to make your checks only in respmod request. But you know beter than me your requirements. 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 ... I am not sure but I think that the best place to put your classification data is the request_t structure. Regards, Christos
