[squid-dev] Issue detected in squid 2.7 version

[scanty babu]

Hi Amos,

We are using squid 2.7 version for legacy reasons.
I will try reproducing the issue in 3.x version and  file a bug in bugzilla.

Thanks,
scanty

On Fri, Oct 31, 2014 at 11:10 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 31/10/2014 6:20 p.m., scanty babu wrote:
>> Hi,
>>
>> We are using squid 2.7.7 version in our production environment and
>> recently faced an issue with this version.
>
> Hi Scanty,
>  Squid Project support for 2.7 was dropped several years ago. Are you
> able to upgrade to a currently supported version?
>
>
>>
>> The scenario: 1. Slow Client side connection 2. Fast Server side
>> connection 3. Client sends a range request from the end eg. 10000
>> byte Content length and the client requests 0-9500 bytes.
>>
>> Client connection being slow, the server side reads get
>> automatically stopped when the data to be written to the client is
>> more than the ReadAhead gap(16KB, default in our case).
>>
>> The server side reads are resumed when all the data in memory has
>> been written to the client. The mechanism of defer and resume keeps
>> occurring during the length of the download.
>>
>> This mechanism works properly in most of the cases, except where
>> Range request are involved. The client gets the requested range of
>> bytes, but does not flip DEFER_READ flag on the server side FD. So,
>> server reads wait for about 15 minutes(timeout) and connection is
>> closed. The HTTP object is released from the store even though the
>> server has sent the complete object.
>>
>>
>> The solution: fwdDeferReadCheck function checks if the server side
>> reads have to be resumed/deferred. As DEFER_READ flag is still set
>> on the FD reads will never resume.So, we put a check
>>
>>
>> -    if (EBIT_TEST(e->flags, ENTRY_DEFER_READ)) { +
>> Server-side fd stuck in defer state after client has received the
>> byte range requested by it. +       Unblocking the server side
>> connection, if there is no pending client waiting on a store entry
>> object. +       If the pending data is more than quick_abort_max,
>> then the connection will be aborted by squid +    */ +    if
>> (EBIT_TEST(e->flags, ENTRY_DEFER_READ) && +
>> storePendingNClients(e)!=0 ) { commDeferFD(mem->serverfd); return
>> 1; }
>>
>> If there is more data to be read from the server, the
>> quick_abort_max configuration will make sure squid aborts the
>> connection
>>
>> Just wanted to bring to notice this issue in 2.7 version, so that
>> it can be fixed in latest squid versions 3.x (if present).
>>
>> Also, please advise if we are doing it correctly (or if it could
>> be done otherwise).
>
> Bug reports should be submitted through our bugzilla. But they will
> only be accepted if they can be demonstrated to occur in the latest
> supported version.
>
> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUUyDWAAoJELJo5wb/XPRj5RUIAJPJtw0LUjt6a1sGFzsq4GUv
> 7oZg6rwWUf81sa76a87Y6MsDDKo4JRZhwGTChlcV8xYNfxLB+oMoqgQoFjORj7fU
> e/v2+pVRhlkW8giXG0eBrE6Srp3CGXE69BvBSip9ArtMsDrOmYEvFwiucGWYAo4r
> uVt4bBmnYCS30OQ/ZustliZa2+RdW6jKwDJiuMTJs3Kk9o+xkOAzXjICuQVqFj7B
> rximbl6J0XZ0QnhmATO3b8wB0JgS0zdCAUylVV2DCs/ARTg3YffaSgy8gIvDa3qq
> ZXxA2zaKN2V6sxXlKcJ4HaeIdvQfR2xbR6QKN/+AU5gkWdk1JdA5FfNjs+hwZbE=
> =4m3Z
> -----END PGP SIGNATURE-----
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev