Re: [squid-users] Question about ICAP.

On 7/7/2012 7:52 AM, Amos Jeffries wrote:
<SNIP>
>>
>> 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.
which i have problem to do because i then need to have some monitoring
over the cached object which is not possible now.

>> 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.
>
well yes i took the time to read a bit an it seems that ICAP design in
not allowing changing the request on the response but allows to give you
a full response on a reqmod.

>> 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.
>
and my question: what is supported by squid these days?
the Link header is a very nice idea.
it can be an elegant solution because it give ICAP have the advantage of
inspecting all the headers and there for will make it better then the
old store_url and also other stdin\stout helpers.
is there any status on the Link header?

<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.

well this was just an example which was used for testing sometime ago.

>
>
> Amos

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il