Re: reply body modification

From: Adrian Chadd <adrian@dont-contact.us>
Date: Sat, 6 May 2006 18:06:26 +0800

Could you share the patch?

adrian

On Sat, May 06, 2006, Michael Ulbrich wrote:
> Hi all,
>
> I'm running an experimental version of squid-2.5.STABLE12 with patches
> that allow for modifiying the client reply body. Patches have been
> applied mostly to client_side.c and especially clientSendMoreData().
>
> Since I need a chunk of body data which meets certain size criteria, I
> check the size parameter on entry to clientSendMoreData() and return
> without sending anything to the client if not enough data is available.
> For practical reasons, I chose to wait until CLIENT_SOCK_SZ (default 4k)
> bytes are passed via buf.
>
> Returning from clientSendMoreData() is accomplished by calling
>
> clientWriteComplete(fd, NULL, 0, 0, http);
> memFree(buf, MEM_CLIENT_SOCK_BUF);
> httpReplyDestroy(rep);
> return;
>
> This has been tested and works ok up to CLIENT_SOCK_SZ=16384.
>
> A further increase of CLIENT_SOCK_SZ to 32k leads to a strange
> phenomenon, in that reading the reply of the origin server often seems
> to starve out at sizes around 17k. Although the origin server keeps on
> sending data and seems to fill the receiving socket buffer (netstat
> claims that sufficient data is available for reading), the associated
> file descriptor never comes back via comm_poll() signalling that new
> data has arrived.
>
> AFAIK this strange behaviour only occurs, when data is read from a
> distant server and httpReadReply() is called several times with small
> chunks of data (e.g. 12x1448bytes). Serving the same data from a local
> httpd, seems to work flawlessly since the receiving buffer is mostly
> filled by only one call to httpReadReply().
>
> I'd very much appreciate, if somebody could give me any pointers where
> to look further and probably find a solution to this problem.
>
> TIA + best regards ... Michael Ulbrich
>
Received on Sat May 06 2006 - 04:08:08 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:04 MDT