On Wed, Mar 27, 2019, at 4:23 PM, Alex Rousskov wrote: > On 3/27/19 3:17 PM, squid@xxxxxxxxxxxxxx wrote: > > Operating in reverse proxy mode. I'm trying to send a TCP reset in response to the acl below: > > > > acl example_url url_regex -i [^:]+://[^0-9]*.example.com.* > > deny_info TCP_RESET example_url > > http_access deny example_url > > > > Looking at the packets I see the following response: > > > > HTTP/1.0 403 Forbidden > > Server: squid > > Mime-Version: 1.0 > > Date: Wed, 27 Mar 2019 20:36:20 GMT > > Content-Type: text/html > > Content-Length: 5 > > X-Squid-Error: TCP_RESET 0 > > Vary: Accept-Language > > Content-Language: en > > X-Cache: MISS from www.example.com > > X-Cache-Lookup: NONE from www.example.com:80 > > Via: 1.0 www.example.com (squid) > > Connection: keep-alive > > > > reset > > > > Squid sends the headers and the word reset. > > FWIW, I cannot reproduce this problem in simple Squid v5 tests. I get > the expected behavior (a connection reset) and the expected cache.log > entry (with debug_options set to ALL,9): > > 2019/03/27 16:05:49.365| 4,2| errorpage.cc(714) errorAppendEntry: RSTing > this reply > > 2019/03/27 16:05:49.372| 33,3| client_side.cc(1596) > clientProcessRequestFinished: Sending TCP RST on local=127.0.0.1:3128 > remote=127.0.0.1:46922 FD 13 flags=1 > > If you can reproduce with Squid v4 or later, I suggest sharing your > (compressed) ALL,9 cache.log while reproducing the problem with a single > denied transaction. > > Are you using ICAP or eCAP REQMOD adaptation? > > Can you think of any ACL-driven directives in your squid.conf that might > be accessed _after_ an "http_access deny" rule matches? Due to an old > configuration design bug, deny_info may "forget" that access was denied > by the example_url ACL if Squid has to evaluate other ACLs before > deny_info is checked. A debugging log requested above would expose such > problems. > > > > I'm not sure if it will help, but wanted to try the following to see > > if that will get rid of that initial header being sent. > > > acl example_url url_regex -i [^:]+://[^0-9]*.example.com.* > > deny_info TCP_RESET example_url > > http_reply_access deny example_url > > > Do I still need the http_access deny example_url in addition to the > > http_reply_access deny example_url statement, or does the > > http_reply_access take the place of http_access statement: > > IIRC, http_reply_access does not apply to transactions denied by > http_access -- Squid does not check its own access denial response. Bugs > notwithstanding, your earlier/simpler configuration should work. > > Alex. > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > Thank you for the reply and I should have mentioned that we are on a pre 4 version at the moment with plans to upgrade. I was looking at a way to fix this behavior in the meantime. Not using ICAP or eCAP REQMODl. I don't see anything that would come after a http_access_deny rule matches but will check further. Is using the http_reply_access deny a viable option if all else fails to correct the issue until we can upgrade? I'm still a bit confused on how to implement it to give it try. Do I need to use http_access with http_reply_access or can http_reply_access be used by itself with deny_info? _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
