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

Graham,

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:

1-
DG+Squid 2.6.STABLE12: No problem of uploading
DG+Squid 3.0.STABLE25: Problematic
DG+Squid 3.1.8: Problematic
DG+Squid 3.2.0.2: 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,

--
Oguz YILMAZ
On Thu, Nov 25, 2010 at 6:36 PM, Graham Keeling <graham_at_equiinet.com> 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.
>