[squid-users] Getting the full file content on a range request, but not on EVERY get ...

Thu May 12 17:09:20 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

IMO better to use

range_offset_limit none !dont_cache_url all

to improve selectivity between non-cached and cached URL's with ACL's....

12.05.16 23:02, Heiler Bemerguy пишет:
>
>
> Hi Garri,
>
> That bug report is mine.. lol
>
> But I couldn't keep testing it to confirm if the problem was about
ABORTING downloads or just trying to download what's already being
downloaded...
>
> When you use quick_abort_min -1, it seems to "fix" the caching issue
itself, but it won't prevent the concurrent downloads, which sucks up
the link..
>
> I don't know if it won't happen with aufs/ufs, I'm using only rock
store.....
>
>
> --
> Heiler Bemerguy - (91) 98151-4894
> Assessor Técnico - CINBESA (91) 3184-1751
>
> Em 12/05/2016 01:01, Garri Djavadyan escreveu:
>> On Wed, 2016-05-11 at 21:37 -0300, Heiler Bemerguy wrote:
>>> Hey guys,
>>> First take a look at the log:
>>> root at proxy:/var/log/squid# tail -f access.log |grep http://download.c
>>> dn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar
>>> 1463011781.572   8776 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.9
>>> application/octet-stream
>>> 1463011851.008   9347 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> 1463011920.683   9645 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.9
>>> application/octet-stream
>>> 1463012000.144  19154 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> 1463012072.276  12121 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> 1463012145.643  13358 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> 1463012217.472  11772 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> 1463012294.676  17148 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> 1463012370.131  15272 10.1.3.236 TCP_MISS/206 300520 GET http://downl
>>> oad.cdn.mozilla.net/pub/firefox/releases/45.0.1/update/win32/pt-
>>> BR/firefox-45.0.1.complete.mar - HIER_DIRECT/200.216.8.32
>>> application/octet-stream
>>> Now think: An user is just doing a segmented/ranged download, right?
>>> Squid won't cache the file because it is a range-download, not a full
>>> file download.
>>> But I WANT squid to cache it. So I decide to use "range_offset_limit
>>> -1", but then on every GET squid will re-download the file from the
>>> beginning, opening LOTs of simultaneous connections and using too
>>> much bandwidth, doing just the OPPOSITE it's meant to!
>>>
>>> Is there a smart way to allow squid to download it from the beginning
>>> to the end (to actually cache it), but only on the FIRST request/get?
>>> Even if it makes the user wait for the full download, or cancel it
>>> temporarily, or.. whatever!! Anything!!
>>>
>>> Best Regards,
>>> --
>>> Heiler Bemerguy - (91) 98151-4894
>>> Assessor Técnico - CINBESA (91) 3184-1751
>>> _______________________________________________
>>> squid-users mailing list
>>> squid-users at lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>> Hi, I believe, you describe the bug http://bugs.squid-cache.org/show_bu
>> g.cgi?id=4469
>>
>> I tried to reproduce the problem and have found that the problem
>> appears only with rock storage configurations. Can you try with
>> ufs/aufs storage?
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXNLi/AAoJENNXIZxhPexG5aAH/juZyvly/aSIguez9dAKPbbb
AHpPxoky36FYOjlPbqmXjdrMPs9qNGT+Ns7WDxsNZFM0Cfbh5UgBfQc64kFoV0k/
qKseFzDLfSqbL6ppEAg3yh4/NUsBYtjT7hwBzNIUso+OM++vAQ5dJygtIWwFMRmC
nSDgjTaYD/7r2JPOTEtfW8mhbC148tVaq/jAZqsefYji90vnXyLtIW5hUCcTw3nG
L3PWJVhYOgSixD3K2tWu1rpgoK0F0+sqp0xqfh2Vz6BUvNIrB40k3qL7cEUnAPsH
CV/O39f+yr/ggoyOmKcsVv4oQ6i2Q+eEDdy4ML7ed0mNO8nXWx1ORkgMzcxHm6Q=
=NO6/
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160512/8ab7f52d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160512/8ab7f52d/attachment-0001.key>