Hi Amos,
thanks a lot for your explanation. My english is not so perfect - maybe
i understood something incorectly - sorry
you wrote:
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.
so at the moment rep_header in ACL only works, if the cache gives a hit
- correct?
so at the moment, i will not get this working when it's called for the
first time or if it's uncachable:
acl cebay rep_header Set-Cookie ebay
(acl domebay dstdomain www.ebay.de)
header_access Set-Cookie deny cebay (domebay)
() eventually added
because of a cache miss and the paged is fetched from the origin server.
Or is thers any way to block 1 Set-Cookie Header from a server reply?
Thanks for any help but i'm looking for a solution for 1 week now, with
windebug, VS6 and so on.
Andreas
Amos Jeffries schrieb:
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
