[squid-users] Deny_Info TCP_RESET

[Alex Rousskov]

On 3/28/19 8:13 AM, creditu at eml.cc wrote:

> Is using the http_reply_access deny a viable option if all else fails
> to correct the issue until we can upgrade?

Probably it is not: I am not sure, but based on my quick reading of the
code and a basic test, http_reply_access does not support the "deny_info
TCP_RESET" feature at all. Only http_access (and possibly
adapted_http_access, but I did not check) supports that feature (bugs
notwithstanding).

In the ideal world, "deny_info TCP_RESET" would work regardless of which
directive (http_access, adapted_http_access/http_access2, or
http_reply_access) is denying access. I may have assumed that ideal in
my earlier response, but this is not what was hacked into Squid AFAICT.


> I'm still a bit confused on how to implement it to give it try.

There is pretty much no relationship between the three access checking
directives mentioned above. They are checked in their natural order, and
the first denial stops further transaction progress, with the denial
page delivered to the client. If you understand how http_access works,
you can apply that understanding to the other two directives.


> Do I need to use http_access with http_reply_access 

No, you do not:

* http_access checks whether HTTP client request should be forwarded (to
the server.

* http_reply_access checks whether HTTP server response should be
forwarded to the client. Naturally, there is no server response to speak
of if the request was previously denied using http_access.


> can http_reply_access be used by itself with deny_info?

You can, but http_reply_access does not support the TCP_RESET feature.
Fixes and fix sponsorship welcomed.


HTH,

Alex.