Re: [squid-users] squid-3.1 client POST buffering

From: Oguz Yilmaz <>
Date: Mon, 29 Nov 2010 17:04:04 +0200


This is the best explanation I have seen about ongoing upload problem
in proxy chains where squid is one part of the chain.

On our systems, we use Squid 3.0.STABLE25. Before squid a
dansguardian(DG) proxy exist to filter. Results of my tests:

DG+Squid 2.6.STABLE12: No problem of uploading
DG+Squid 3.0.STABLE25: Problematic
DG+Squid 3.1.8: Problematic
DG+Squid Problematic

2- We have mostly prıblems with the sites with web based upload status
viewers. Like rapidshare, youtube etc...

3- If Squid is the only proxy, no problem of uploading.

4- ead_ahead_gap 16 KB does not resolv the problem

Dear Developers,

Can you propose some other workarounds for us to test? The problem is
encountered with most active sites of the net, unfortunately.

Best Regards,

On Thu, Nov 25, 2010 at 6:36 PM, Graham Keeling <> wrote:
> Hello,
> I have upgraded to squid-3.1 recently, and found a change of behaviour.
> I have been using dansguardian in front of squid.
> It appears to be because squid now buffers uploaded POST data slightly
> differently.
> In versions < 3.1, it would take some data, send it through to the website,
> and then ask for some more.
> In 3.1 version, it appears to take as much from the client as it can without
> waiting for what it has already got to be uploaded to the website.
> This means that dansguardian quickly uploads all the data into squid, and
> then waits for a reply, which is a long time in coming because squid still
> has to upload everything to the website.
> And then dansguardian times out on squid after two minutes.
> I noticed the following squid configuration option. Perhaps what I need is
> a similar thing for buffering data sent from the client.
> #  TAG: read_ahead_gap  buffer-size
> #       The amount of data the cache will buffer ahead of what has been
> #       sent to the client when retrieving an object from another server.
> #Default:
> # read_ahead_gap 16 KB
> Comments welcome!
> Graham.
Received on Mon Nov 29 2010 - 15:04:31 MST

This archive was generated by hypermail 2.2.0 : Tue Nov 30 2010 - 12:00:03 MST