<div dir="ltr"><span style="font-family:Arial,Helvetica,sans-serif;white-space:pre-wrap">It's all pretty clear to me now after I read RFC and found relationship between that and refresh_pattern usage.</span><br><div><span style="font-family:Arial,Helvetica,sans-serif;white-space:pre-wrap">Thank you.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 1, 2017 at 4:46 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/09/17 00:18, Alexander Lazarev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well. looks like squid using heuristics after all:<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(291) refreshCheck: checking freshness of '<a href="http://mydomain.zone/1.txt" rel="noreferrer" target="_blank">http://mydomain.zone/1.txt</a>'<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(312) refreshCheck: Matched '<none> 0 20%% 259200'<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(314) refreshCheck: age: 65955<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(316) refreshCheck: check_time: Fri, 01 Sep 2017 11:49:12 GMT<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(318) refreshCheck: entry->timestamp: Thu, 31 Aug 2017 17:29:57 GMT<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(179) refreshStaleness: No explicit expiry given, using heuristics to determine freshness<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(198) refreshStaleness: Last modified 5524975 sec before we cached it, L-M factor 20.00% = 1104995 sec freshness lifetime<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(205) refreshStaleness: FRESH: age 65955 <= stale_age 1104995<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(338) refreshCheck: Staleness = -1<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(461) refreshCheck: Object isn't stale..<br>
2017/09/01 14:49:12.296 kid2| 22,3| refresh.cc(470) refreshCheck: returning FRESH_LMFACTOR_RULE<br>
<br>
It's a shame there's no warning header, like "<a href="https://tools.ietf.org/html/rfc7234#section-5.5.4" rel="noreferrer" target="_blank">https://tools.ietf.org/html/r<wbr>fc7234#section-5.5.4</a>" suggests.<br>
</blockquote>
<br></span>
There should be when that cached response becomes 24 hrs old. That log says Squid only received the object ~18 hrs ago, so the cached *response* has not been around for 24hrs yet even though the *content* it refers to on the server is older.<br>
<br>
Content on a server being old is no particular cause for alarm if it gets cached a few seconds/hrs/mins on a proxy.<br>
<br>
Though note that Warning headers about heuristics being used are an OPTIONAL, so it is also not a problem if they are absent.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Guess, I need to set refresh_pattern's max option to minimal value.<br>
<br>
</blockquote>
<br></span>
Any particular reason you are worried about all this?<br>
<br>
Heuristic freshness is normal and usually perfectly fine. A proxy making heuristic decisions is only a problem if it is ignoring server or client instructions about the content cacheability. Also, a reverse-proxy as an agent of the server effectively has permission to ignore things the client wants - though it is usually a good idea to do a background revalidation if the client insists strongly on new content (eg. reload-into-ims option), because that tends to mean there is some problem with what it got earlier [maybe whats in the cache].<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Aug 31, 2017 at 8:26 PM, Alexander Lazarev wrote:<br>
<br>
Thank you for reply!<br>
I still don't understand what's happening.<br>
I create file 1.txt with a little bit of text data. Request it with<br>
curl. Web-server returns it without any cache related headers to<br>
squid, squid returns it to me. Getting it with curl one more time,<br>
squid serves it straight from cache without validation(no entries in<br>
log on origin server).<br>
I create one more file 2.txt with some data. Do same things, same<br>
headers in response. Second response from squid is from cache but<br>
validated from origin server(i see 304 in origin server logs).<br>
What could be wrong?<br>
</blockquote>
<br></span>
Nothing wrong. Both sequences are valid and normal. The difference could just be a timing variation as small as a nanosecond in what operations are performed relative to each other - with heuristics based on 0.2 of a recently created objects age HTTP's 1 second in timing resolution is both very course and very sensitive to rounding limits.<div class="HOEnZb"><div class="h5"><br>
<br>
Amos<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/l<wbr>istinfo/squid-users</a><br>
</div></div></blockquote></div><br></div>