On 05/10/2016 09:16 AM, Amos Jeffries wrote:
> On 11/05/2016 2:03 a.m., Eduard Bagdasaryan wrote:
>> Hello,
>>
>> This patch allows chunking the last HTTP response on a connection.
>> Squid should avoid signaling the message end by connection closure
>> because it hurts message integrity and someti
On 11/05/2016 2:03 a.m., Eduard Bagdasaryan wrote:
> Hello,
>
> This patch allows chunking the last HTTP response on a connection.
> Squid should avoid signaling the message end by connection closure
> because it hurts message integrity and sometimes performance. Squid
> now chunks if:
>
> 1. t
Hello,
This patch allows chunking the last HTTP response on a connection.
Squid should avoid signaling the message end by connection closure
because it hurts message integrity and sometimes performance. Squid
now chunks if:
1. the response has a body;
2. the client claims HTTP/1.1 support; a
On 05/10/2016 01:50 AM, Amos Jeffries wrote:
> Then each peer gets its own re-lookup event scheduled
If applied correctly, this approach would also solve the misapplication
problem I described in my concurrent review. Unfortunately, it requires
serious work. Fortunately, you have already converte
On 05/09/2016 08:41 PM, Nathan Hoad wrote:
> +NAME: cache_peer_negative_dns_ttl
> +COMMENT: time-units
> +TYPE: time_t
> +LOC: Config.cachePeerNegativeDnsTtl
> +DEFAULT: 1 minutes
> +DOC_START
> + How often to retry failed DNS lookups for cache peers.
It is not actually clear what this means b
On 10/05/2016 2:41 p.m., Nathan Hoad wrote:
> Hello,
>
> Attached is a patch which makes Squid attempt to resolve failed DNS lookups
> for cache peers more frequently than an hour. It's user configurable, with
> a default of one minute.
>
IMO the proper fix for this behaviour is to deliver the a
