On 10/05/2016 05:49 PM, squid-us...@filter.luko.org wrote:
>> 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-
Alex,
> 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:
>
> >
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 s
> > 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_repl
On 10/04/2016 05:18 AM, Amos Jeffries wrote:
> On 4/10/2016 11:53 p.m., squid-us...@filter.luko.org wrote:
>> Would the developers be open to adding a configuration-based throttle to
>> authentication responses
> This helper is the mechanism that we accepted. Anything else would be
> far less use
On 5/10/2016 12:47 a.m., squid-users wrote:
> Amos,
>
>> This helper is the mechanism that we accepted. Anything else would be far
>> less useful.
>
> Makes sense.
>
>> I think the results you are getting show that the http_status ACL is not
>> working properly.
>>
>> Can you get a "debug_option
Amos,
> This helper is the mechanism that we accepted. Anything else would be far
> less useful.
Makes sense.
> I think the results you are getting show that the http_status ACL is not
> working properly.
>
> Can you get a "debug_options 28,5" cache.log trace and see if
> "aclMatchHTTPStatus" i
On 4/10/2016 11:53 p.m., squid-us...@filter.luko.org wrote:
> Eliezer,
>
> Thankyou for your reply, I tried the following:
>
>> Hey Luke,
>>
>> Try to use the next line instead:
>> external_acl_type delay ttl=1 negative_ttl=0 cache=0 %SRC %SRCPORT %URI
>> /tmp/delay.pl
>>
>> And see what happens
Eliezer,
Thankyou for your reply, I tried the following:
> Hey Luke,
>
> Try to use the next line instead:
> external_acl_type delay ttl=1 negative_ttl=0 cache=0 %SRC %SRCPORT %URI
> /tmp/delay.pl
>
> And see what happens.
But it's not introducing a delay into the response. Running strace ac
On 14/09/2016 12:18 p.m., squid-us...@filter.luko.org wrote:
> Hi Squid users,
>
> Seeking advice on how to slow down 407 responses to broken Apple & MS
> clients, which seem to retry at very short intervals and quickly fill the
> access.log with garbage. The problem is very similar to this:
>
>
:18 AM
To: squid-users@lists.squid-cache.org
Subject: [squid-users] Introducing delay to HTTP 407 responses
Hi Squid users,
Seeking advice on how to slow down 407 responses to broken Apple & MS
clients, which seem to retry at very short intervals and quickly fill the
access.log with garbage.
I just want to throw my support behind seeking a solution to this problem.
Luke’s clearly considered it in way more detail than anyone so far, myself
included.
The affects the squids under my purview every day.
Best,
Dan
> On 14 Sep. 2016, at 10:18 am, squid-us...@filter.luko.org wrote:
>
> H
Hi Squid users,
Seeking advice on how to slow down 407 responses to broken Apple & MS
clients, which seem to retry at very short intervals and quickly fill the
access.log with garbage. The problem is very similar to this:
http://www.squid-cache.org/mail-archive/squid-users/201404/0326.html
Howe
13 matches
Mail list logo
