[squid-dev] Issue detected in squid 2.7 version

Amos Jeffries squid3 at treenet.co.nz
Fri Oct 31 05:40:38 UTC 2014

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.

Version: GnuPG v2.0.22 (MingW32)


More information about the squid-dev mailing list