On Wed, 2016-05-11 at 21:37 -0300, Heiler Bemerguy wrote: > > Hey guys, > First take a look at the log: > root@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@xxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
