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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
