On 30/11/10 21:23, Oguz Yilmaz wrote:
On Tue, Nov 30, 2010 at 10:05 AM, Amos Jeffries<squ...@treenet.co.nz> wrote:
On 30/11/10 04:04, Oguz Yilmaz wrote:
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.
This sounds like the same problem as
http://bugs.squid-cache.org/show_bug.cgi?id=3017
Sorry, crossing bug reports in my head.
This one is closer to the suck-everything behaviour you have seen:
http://bugs.squid-cache.org/show_bug.cgi?id=2910
both have an outside chance of working.
In my tests, no NTLM auth was used.
The browser has proxy confguration targeting DG and DG uses squid as
provider proxy. If you think it will work, I can try the patch
located in the bug case.
Upload will stop at about 1MB, so is it about SQUID_TCP_SO_RCVBUF?
AIUI, Squid is supposed to read SQUID_TCP_SO_RCVBUF + read_ahead_gap and
wait for some of that to pass on to the server before grabbing some more.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.9
Beta testers wanted for 3.2.0.3
