On Fri, 2007-03-09 at 17:35 +0530, Siddhesh PaiRaikar wrote: > while finding on ICAP servers i came accross this : there is a squid > web proxy as an ICAP client available. > > in the above response where we are told to use the ICAP server, will > it be helpful in any way to use this squid client in any way .. since > we already have squid on our machines... or do we scrap squid > altogether and use the ICAP. In that case i would need some > suggestions on involving squid in this in some way. To use ICAP, one needs an ICAP client (usually an ICAP-capable HTTP proxy like Squid) and an ICAP server. Thus, if you decide to end the suffering of in-Squid content modification and use ICAP, you will still need Squid or a different ICAP-capable proxy. The point of adding an ICAP server into the mix is to avoid modifying or customizing the proxy (and to allow your solution to work with any ICAP-capable proxy). All your "business logic" will be in the ICAP server. For more details, you may want to read www.i-cap.org documents regarding the ICAP infrastructure. You do not have to write an ICAP server from scratch. There are two or three GPLed ICAP servers available. including the old "reference implementation" from NetApp, linked from the i-cap.org site. You can customize them. <plug>If you want more support and less work, The Measurement Factory builds ICAP servers "to suit" and also provides Traffic Spicer, the bare-bones ICAP server where you can plug in your redirection logic.</plug> FWIW, I know of three primary ways to do ICAP-based redirection: 1) The ICAP server generates a 302 redirection response. The browser then goes to the new origin server. This is simple and the browser does most of the work. However, you need an origin server and you need to coordinate ICAP server and your origin server logic. The whole transaction takes longer. You need to be careful about loops. 2) The ICAP server rewrites the virgin request to go to a different server. This approach is similar to (1) but eliminates network delays. Its additional drawback is that it only works if you can make the redirection decision based on the request: When you receive a virgin response, it is impossible to rewrite that into a request to a different server. 3) The ICAP server can generate the final response. This approach eliminates the network delays like (2) and also allows you to have all processing logic in one place. On the other hand, this approach usually requires that the ICAP server becomes an HTTP server of sorts because the final response is likely to contain embedded images and similar objects. Thus, this approach works best when the final response is very simple and stateless. In general, I would recommend starting with (1). HTH, Alex.
