<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<p>Hi Garri,<br>
</p>
<p>That bug report is mine.. lol</p>
<p>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...</p>
<p>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..</p>
<p>I don't know if it won't happen with aufs/ufs, I'm using only
rock store.....<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Heiler Bemerguy - (91) 98151-4894
Assessor Técnico - CINBESA (91) 3184-1751</pre>
<br>
<div class="moz-cite-prefix">Em 12/05/2016 01:01, Garri Djavadyan
escreveu:<br>
</div>
<blockquote cite="mid:1463025679.14398.4.camel@comnet.uz"
type="cite">
<pre wrap="">On Wed, 2016-05-11 at 21:37 -0300, Heiler Bemerguy wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hey guys,
First take a look at the log:
root@proxy:/var/log/squid# tail -f access.log |grep <a class="moz-txt-link-freetext" href="http://download.c">http://download.c</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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 <a class="moz-txt-link-freetext" href="http://downl">http://downl</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
</pre>
</blockquote>
<pre wrap="">
Hi, I believe, you describe the bug <a class="moz-txt-link-freetext" href="http://bugs.squid-cache.org/show_bu">http://bugs.squid-cache.org/show_bu</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
</pre>
</blockquote>
<br>
</body>
</html>