[squid-users] Re: redirection

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.
Received on Fri Mar 09 2007 - 08:39:24 MST