[squid-users] Introducing delay to HTTP 407 responses

[Alex Rousskov]

On 10/04/2016 06:20 AM, Amos Jeffries wrote:
> On 5/10/2016 12:47 a.m., squid-users wrote:

>> I set this up as you suggested, then triggered a 407 response from
>> the cache.  It seems that way; I couldn't see aclMatchHTTPStatus or
>> http-response-407 in the log


> Strange. I was sure Alex did some tests recently and proved that even
> internally generated responses get http_reply_access applied to them.


Yes, see
http://lists.squid-cache.org/pipermail/squid-users/2016-August/012048.html

However, there is a difference between my August tests and this thread.
My tests were for a request parsing error response. Access denials do
not reach the same http_reply_access checks! See "early return"
statements in clientReplyContext::processReplyAccess(), including:

>     /** Don't block our own responses or HTTP status messages */
>     if (http->logType.oldType == LOG_TCP_DENIED ||
>             http->logType.oldType == LOG_TCP_DENIED_REPLY ||
>             alwaysAllowResponse(reply->sline.status())) {
>         headers_sz = reply->hdr_sz;
>         processReplyAccessResult(ACCESS_ALLOWED);
>         return;
>     }

I am not sure whether avoiding http_reply_access in such cases is a
bug/misfeature or the right behavior. As any exception, it certainly
creates problems for those who want to [ab]use http_reply_access as a
delay hook. FWIW, Squid had this exception since 2007:

> revno: 8474
> committer: hno
> branch nick: HEAD
> timestamp: Thu 2007-08-30 19:03:42 +0000
> message:
>   Bug #2028: FATAL error if using http_reply_access in combination with authentication
>   
>   The attached patch bypasses http_reply_access on access denied messages
>   generated by this Squid, and also optimizes processing slightly in the
>   common case of not using any http_reply_access rules at all.


HTH,

Alex.