Thanks Amos. We're using the CONNECT ACL and everything is working as
expected.
On 29 April 2015 at 20:28, Amos Jeffries squ...@treenet.co.nz wrote:
On 29/04/2015 5:44 p.m., dan wrote:
I mentioned last time that we had to x2 all our delay_parameter’s
bytes because of a weird bug where squid
On 29/04/2015 5:44 p.m., dan wrote:
I mentioned last time that we had to x2 all our delay_parameter’s
bytes because of a weird bug where squid would apply it at half speed
for no reason.
It just occurred to me that (obviously) this is why HTTPS downloads
are going too fast; because this bug
I mentioned last time that we had to x2 all our delay_parameter’s bytes because
of a weird bug where squid would apply it at half speed for no reason.
It just occurred to me that (obviously) this is why HTTPS downloads are going
too fast; because this bug must only affect HTTP traffic.
On 17/04/2015 1:30 p.m., djch wrote:
I just wanted to revive this thread to note that:
- Delay pools apply just fine to HTTPS requests in Squid 2.7.
- Delay pools in Squid 3.4.x are also applied to HTTPS but the speed is not
correct.
- If I apply a 56 Kbps limit the HTTP download tops
Thanks Amos
Sorry if that wasn’t clear, but yeah, 7 KB/s was the desired speed in that
test.
I was testing against an ISO in an S3 bucket of ours. I would start the
download using http:// and get 7 KB/s (great). Then cancel it and edit the URL
to https:// and get ~90 KB/s.
Oh, and
I have set up a delay pool in order to restrict bandwidth to a specific
client, and it works just fine. That client starts downloading multiple big
files, and the bandwidth consumed is limited as set up. But... when this
client goes to youtube and starts viewing hd videos, the bandwidth consumed
On Wednesday 20 August 2014 at 22:14:06 (EU time), fpap wrote:
I have set up a delay pool in order to restrict bandwidth to a specific
client, and it works just fine. That client starts downloading multiple big
files, and the bandwidth consumed is limited as set up. But... when this
client
