On 06/19/2013 01:27 PM, Amos Jeffries wrote:
On 19/06/2013 8:33 p.m., Eliezer Croitoru wrote:
i took this from the acls docs:
acl aclname rep_mime_type [-i] mime-type ...
# regex match against the mime type of the reply received by
# squid. Can be used to detect file download or some
# types HTTP tunneling requests. [fast]
# NOTE: This has no effect in http_access rules. It only has
# effect in rules that affect the reply data stream such as
# http_reply_access.
and I was wondering if this is suppose to work:
acl response_mime rep_mime_type "some mime type"
cache deny dstdom_acl response_mime
cache allow all
I remeber that using a status code like 30x for the same task wouldn't
work.
The "cache" access permissions is determining whether the storage
components of Squid take part in the transaction handling. The original
semantics of it was to determine whether Squid assumed a "no-cache"
header was present if none was actually sent by the client. In order to
control HIT's that has to be done before the response is known.
There is no reason why we can't have a different access control ("store
allow/deny ...") making things non-cacheable based on the response, just
as if the server had sent a no-store header. Patches welcome.
Amos
Welcome indeed.
For now We can use two things:
ICAP service that will mark the response as no-store that is already
being looked upon as "no-cache at all" and a probe in the StoreID helper
which uses a small crawler to findout if the request is predicted to be 302.
When can we have some time to think together on the ICAP StoreID
integration I will be happy to thing about it.
Just a note out of the tpic for Alex:
about my approach to program and later fix bugs.
My approach is and was program something perfect first if you can but
later on fix bugs only if you must.
There was a need for StoreID which I think made squid way of handling
cache objects more clear now.(and not only to me)
Now we can check and verify what problems are coming from wrong coding
of vary like headers or just wonder if the code is bad or not.
StoreID proved that if you see a TCP_MISS then there is a good reason
for that and if not you need to think again if you see a TCP_MISS or was
just day dreaming.
Also I think that the way I explained X_IMS_UNMODIFIED is now a based
ground for people who actually don't know how to investigate their logs.
Take a peak at this:
http://www1.ngtech.co.il/moin/Squid/StoreID
Which I will later on make couple video tutorials that explain how squid
handles requests from another point of view rather then read 30-40k
lines of code.
Eliezer
