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
