[squid-users] Deny_Info TCP_RESET

[creditu at eml.cc]

On Wed, Mar 27, 2019, at 4:23 PM, Alex Rousskov wrote:
> On 3/27/19 3:17 PM, squid at buglecreek.com 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 at lists.squid-cache.org
> 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?