Re: [squid-users] Question about ICAP.

On 7/07/2012 3:57 p.m., Eliezer Croitoru wrote:
> i already asked before once.
> i want to prioritize ICAP services by specific order like :
> basicfiltering depth filtering
>
> so i use: adaptation_service_chain ??
> as far i understand it will make the checks by order.
> and what if one of the ICAP services has deny acl for the url?
> let say
>
> #request: http://www.google.com/
> acl google dstdomain .google.com
> adaptation_service_chain urlFilter logger1 logger2
> urlFilter allow all
> logger1 deny google
> logger1 allow all
> logger2 allow all
>
> ?

[my knowledge of this part is weak, so YMMV]
As I understand it the service chain is just the default ordering. Any
services which cannot service the particular details will be omitted
from the service chain actually used.

>
> another question is:
> ICAP respmod_precache from squid has i have seen will send the request
> url.
> and i'm not sure (i dont remember ICAP rfc) if the RESPMOD suppose to
> send the request url as part of the protocol.
> can i send in the RESPMOD the request url and by that change the url
> that the content will be stored at?

I don't believe so. The RESPMOD is pre-cache, but to Squid that only
means the cache location has been determined, opened and awaiting data.
These services are modifying what will fill into that. You need a
REQMOD service to modify any request details. Squid REQMOD is carefully
been made pre-cache as well so that the caching properties can be modified.

But you don't need store_url to de-duplicate when ICAP can replace the
whole video with a redirect to the previously stored videos URL.

> in the Encapsulated header i am getting the request and the response.
> in a REQMOD i am responding with:
> Encapsulated: req-hdr=0, null-body="some_byte_number"
> maybe i can response to a RESPMOD with header like:
> Encapsulated: req-hdr=0, res-hdr=583, res-body=850
>

To modify the response sometimes the request details are required. That
does not mean you can modify the request details. At that stage they are
read-only.

> and to change the request header.. then on squid the cached url will
> be the one from the ICAP server response and then there is no longer
> need for "store_url_rewrite" at all because ICAP can replace
> url_rewrite and store_url_rewrite..

If you want to look into updating ICAP to pass back an altered key for
Squid we can look into that as a store_url replacment. Store URL
de-duplication was an experimental feature which never really stabilized
properly for the YT use-case it was supposed to handle (that nasty
redirect patch and the recent multi-encoding issues).

There are other possibilities as well, Digest: and alternative-URI Link:
location features of HTTP need better support in Squid and could be used
to replace store_url features.

Digest: with a cache indexed on object digest hashes allows client some
control over when de-duplication is performed. By requesting a hash
match when URL MISSes (or not).

The Link: support would be particularly useful in replacing store_url.
It allows responses to register multiple duplicating sets of URL. With
one reply Squid could index the alternatives and HIT on multiple other
URLs in future requests. This one would be controllable with RESPMOD,
Link being a response header.

>
> Thanks,
> Eliezer
>
> this is a basic ICAP RESPMOD session sample to work with..:
> RESPMOD icap://127.0.0.1:1344/respmod ICAP/1.0
> Host: 127.0.0.1:1344
> Date: Sat, 07 Jul 2012 03:42:40 GMT
> Encapsulated: req-hdr=0, res-hdr=583, res-body=850
> Preview: 0
> Allow: 204
>
> GET http://www.google.com/ HTTP/1.1
> Host: www.google.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0)
> Gecko/20100101 Firefox/13.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip, deflate
> Cookie:
> PREF=ID=3f1a1925884751e3:U=726510ee09cc5141:FF=0:LD=en:TM=1317970640:LM=1339099594:GM=1:S=VsYoiMXWKW5OPJaK;
> NID=60=hSChbnc5ZvZSldPGywiQG9OkjCYFC9NNLXWHWg84bCsDeD1g7mvD3uN0nObnb17DnuWLeAi5nsmgHvqlbSvV_9qJuHUqbT0j9q1ydyCodwqCvxLrF-yd69ZzBHf5xxZyPyBn_0KkOxbbYH2YAGyJuEU;
> OGPERM=W6%3D0.0.4.60
>
> HTTP/1.1 302 Moved Temporarily
> Location: http://www.google.co.il/
> Cache-Control: private
<snip>
> 0
>
> ICAP/1.0 200 OK
> ISTag: "GreasySpoon-1.0.8-01"
> Host: 127.0.0.1:1344
> Encapsulated: res-hdr=0, res-body=295
> Connection: close
>
> HTTP/1.1 302 Moved Temporarily
> Location: http://www.google.co.il/
> Cache-Control: no-cache, no-store, must-revalidate

Strange modification.

no-store overrides no-cache and must-revalidate, both of which only
operate on stored content sometime in the future. It is useless waste of
bytes placing all three in one cache-control header.

Squid being a shared proxy "private" and "no-store" are handled the
same. So all this does is prevent the browser caching the 304 on the
users machine.

Amos
Received on Sat Jul 07 2012 - 04:52:53 MDT