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
