Thanks Amos. We're using the CONNECT ACL and everything is working as
expected.
On 29 April 2015 at 20:28, Amos Jeffries 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 would apply it
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 thi
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.
So
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
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 to
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 out at ~7 KB/s. If I
download the same file fr
