[squid-users] Deny_Info TCP_RESET

Alex Rousskov rousskov at measurement-factory.com
Wed Mar 27 22:23:28 UTC 2019


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.


More information about the squid-users mailing list