Re: [squid-users] header_access rep_header info from A. Jeffries

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
Received on Wed Nov 28 2012 - 16:28:37 MST