On 28/11/2012 10:51 p.m., A. W. wrote:
Hi all,
in Jan 2009 Amos Jeffries wrote for Squid 3.0-STABLE12 why rep_header
Cookie: gives error "clear_logged_in_user_cookie' ACL is used but
there is no HTTP reply -- not matching"
here:
http://www.squid-cache.org/mail-archive/squid-users/200901/0501.html
"Squid checks to see whether something is allowed to be cached at the
time it is requested. Not when the reply is already coming back.
Seems daft yes, but thats the way its currently done.
Which means until someone gets time or money to clean that up, you can
only use request or connection information in the cache ACLs.
Amos"
To my understanding then, all the function that rely on a reply-Header
didn't work at that moment - correct?
Yes. But...
Is this only for the caching mechanism or also for the delivery to the
client?
"cache allow/deny" tim and "http_reply_access" are to very different
period of the transaction lifecycle.
Simplifying this down a LOT:
1) client send Squid a request
2) check http_access to see if the request is permtted handling
3) check for url_redirect, adaptations etc on the request details
4) check "cache" directive for whether to store the transaction in cache.
5) check storage to see if the request is a HIT, if it is skip to (11)
6) check miss_access to see if MISS is able to be fetched from the network
7) check cache_peer_access / allow_direct/never_direct etc to see where
the request might come from
8) check request_header_access while constructing a outbound request
9) send request to some server
10) receive server response back
11) check http_reply_access to see if the reply is allowed to be
delivered to the client
12) check reply_header_access to see what headers are allowed to be
delivered to the client.
13) .. finally deliver the reply to client
Between (1) and (11) reply headers do not exist, cannot be checked.
Notice how "cache" storage directive is at (4), peer source selection is
at (7) etc. None of those directives and some others involved with minor
transaction features between (1) and (11) are able to depend on reply
headers values.
Does any newer or older Version handle rep_header correctly?
They all handle reply headers *correctly*, even back then when I wrote
that message. What I was talking about was use of the "cache" directive
with reply headers. As in "cache deny QUERY" being based on request
information. Hopefully one day someone will get around to re-checking
storeability about 11/12 in the above sequence - when that happens reply
headers will be available on the re-check.
is there any Windows Version handling this correctly?
Your definition of "correctly" needs a lot more explanation please.
Keeping in mind the transacton lifecycle, what exactly is "incorrect"?
Amos
