<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 20/02/15 13:29, Amos Jeffries wrote:<br>
</div>
<blockquote cite="mid:54E728A6.4010606@treenet.co.nz" type="cite">
<pre wrap="">On 20/02/2015 10:55 p.m., Corentin Delcourt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I run two squid servers, siblings with each other, let's call them A and
B. When clients send requests to A, and A thinks B has the resource
cached, but in reality B doesn't,
</pre>
</blockquote>
<pre wrap="">
Use HTCP protocol between the peers, far less false positives than ICP
or digest.
</pre>
</blockquote>
Will do, thanks for the tip.
<blockquote cite="mid:54E728A6.4010606@treenet.co.nz" type="cite">
<blockquote type="cite">
<pre wrap="">the client will get a 504 error with
the message: “Valid document was not found in the cache and
‘only-if-cached’ directive was specified.” Vice versa if clients send
requests to B.
I believe that A should catch this error and fetch the resource
directly, but instead it forwards it to the client, and I cannot figure
out why. I am not using allow-miss.
</pre>
</blockquote>
<pre wrap="">
It should be but there are conditions to that:
* another source of the URL is actually accessible (think IPv6-only
websites, routing outages, DNS lookup failures, Path-MTU failures,
traffic blackholes, etc)
</pre>
</blockquote>
If I re-send a failing request with Cache-Control: no-cache, or if I
remove the cache_peer directive, I don't get any errors at all so it
doesn't seem like this is the problem here.<br>
<blockquote cite="mid:54E728A6.4010606@treenet.co.nz" type="cite">
<pre wrap="">* there is time remaining within the forward_timeout for the alterative
route to be contacted. If the timeout occurs the last error state
encountered will be reported, if there is no earlier error the timeout
itself is mentioned.</pre>
</blockquote>
I believe the default timeout is 4 minutes? I set it explicitely to
10 minutes, and forward-max-tries to 25 for good measure, and
requests are still failing within hundreds of milliseconds so I
don't think this is related.<br>
<blockquote cite="mid:54E728A6.4010606@treenet.co.nz" type="cite">
<pre wrap="">* the 504 is not being cached. That error response is one which is
allowed to be cached by proxies if it gets delivered with cacheability
headers. NP: It could be cached and delivered by either proxy, so even
coming from the other one *it* may still have been cached and what
caused the "HIT" to be identified.
</pre>
</blockquote>
I don't think the error is being served from cache. If I look at the
access logs for both machines I see:<br>
<pre><meta http-equiv="content-type" content="text/html; charset=utf-8">1424437827.131 6 127.0.0.1 TCP_MISS/504 4913 GET <a class="moz-txt-link-freetext" href="http://example.net/">http://example.net/</a> - SIBLING_HIT/10.0.1.2 text/html
</pre>
… on A and<br>
<pre>1424437827.882 0 10.0.1.1 TCP_MISS/504 4801 GET <a class="moz-txt-link-freetext" href="http://example.net/">http://example.net/</a> - HIER_NONE/- text/html</pre>
… on B, 10.0.1.1 being A and 10.0.1.2 being B.
<blockquote cite="mid:54E728A6.4010606@treenet.co.nz" type="cite">
<blockquote type="cite">
<pre wrap="">What confuses me even more is that this didn't happen a month ago, with
the same setup.
</pre>
</blockquote>
<pre wrap="">
... what version of Squid?
... and is it the same setup AND version(s) of Squid from a month ago?
</pre>
</blockquote>
I'm running Squid 3.5.2 on both servers. I was running 3.5.1 on both
a week ago and observing the same problem.<br>
<br>
I can't say for sure which version I was running before this started
happening, but I believe it was 3.4.8 on one machine and 3.4.10 on
the other.<br>
</body>
</html>