On 15/10/2016 1:36 a.m., Yuri Voinov wrote: > > > > 14.10.2016 18:30, Amos Jeffries пишет: >> On 15/10/2016 12:34 a.m., Yuri Voinov wrote: >>> >>> A bit more details. >>> >>> This is 4 transactions in chronological order. Two from wget -S and two >>> from same PC via browser for the same URL: >>> >>> *root @ khorne /tmp # wget -S >>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js* >>> --2016-10-14 17:18:05-- >>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js >>> Connecting to 127.0.0.1:3128... connected. >>> Proxy request sent, awaiting response... >>> HTTP/1.1 301 Moved Permanently >>> Server: nginx >>> Date: Fri, 14 Oct 2016 11:18:07 GMT >>> Content-Type: text/html >>> Content-Length: 178 >>> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js >>> X-Cache: MISS from khorne >>> X-Cache-Lookup: MISS from khorne:3128 >>> Connection: keep-alive >>> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js > [following] >>> --2016-10-14 17:18:07-- >>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js > >> Notice how the Location header made wget fetch send a second fetch to >> *actually* load an HTTPS object. > >> This means your use of HTTP is irrelevant. HTTP just results in an 301 >> response. That is the end of the HTTP... > > Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js > > This is no matter. > > > >>> Connecting to 127.0.0.1:3128... connected. >>> Proxy request sent, awaiting response... >>> HTTP/1.1 200 OK >>> Server: nginx >>> Date: Fri, 14 Oct 2016 10:45:57 GMT >>> Content-Type: application/javascript; charset=windows-1251 >>> Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT >>> ETag: W/"cdf370-758-52351a306ac80" >>> Cache-Control: max-age=3600 >>> Expires: Fri, 14 Oct 2016 11:45:57 GMT >>> Access-Control-Allow-Origin: * >>> Age: 1930 >>> X-Cache: HIT from khorne >>> X-Cache-Lookup: HIT from khorne:3128 >>> Transfer-Encoding: chunked >>> Connection: keep-alive >>> Length: unspecified [application/javascript] >>> Saving to: 'gazeta.media.query.js' >>> >>> gazeta.media.query. [ <=> ] 1.84K --.-KB/s in >>> 0s >>> >>> 2016-10-14 17:18:07 (138 MB/s) - 'gazeta.media.query.js' saved [1880] >>> >>> /HTTP object in cache and HIT./ > >> No. *HTTPS* object in cache and HIT. > Oh, mistype. Let it be HTTPS and HIT. > > > >>> * >>> **root @ khorne /tmp # wget -S >>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js* >>> --2016-10-14 17:18:30-- >>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js >>> Connecting to 127.0.0.1:3128... connected. >>> Proxy request sent, awaiting response... >>> HTTP/1.1 200 OK >>> Server: nginx >>> Date: Fri, 14 Oct 2016 10:45:57 GMT >>> Content-Type: application/javascript; charset=windows-1251 >>> Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT >>> ETag: W/"cdf370-758-52351a306ac80" >>> Cache-Control: max-age=3600 >>> Expires: Fri, 14 Oct 2016 11:45:57 GMT >>> Access-Control-Allow-Origin: * >>> Age: 1953 >>> X-Cache: HIT from khorne >>> X-Cache-Lookup: HIT from khorne:3128 >>> Transfer-Encoding: chunked >>> Connection: keep-alive >>> Length: unspecified [application/javascript] >>> Saving to: 'gazeta.media.query.js.1' >>> >>> gazeta.media.query. [ <=> ] 1.84K --.-KB/s in >>> 0s >>> >>> 2016-10-14 17:18:30 (120 MB/s) - 'gazeta.media.query.js.1' saved [1880] >>> >>> /HTTPS object in cache and HIT too./ > >> No. Same HTTPS object from test #1 is still in cache and still being HIT. > >>> >>> This is ok. > >> Uh, not if you are going to interpret the first test as being an HTTP >> object in cache. > >> What this tells is that fetching an HTTPS object twice in a row will >> produce a HIT. > Yes. Let it be. > > >>> >>> *Ctrl+F5 (force reload) from browser:* >>> >>> 1476443947.419 92 192.168.100.103 TCP_MISS/200 2323 GET >>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js - >>> HIER_DIRECT/81.19.72.0 application/javascript >>> >>> MISS - it is ok too, client browser sends no-cache. > >> Did you check the client request to verify that "no-cache" statement? > Yes. > > >>> >>> At this point we sure object in cache, right? Both in proxy cache and in >>> client cache (client is the same in attempt 3 and 4). Now - refresh from >>> browser on the same page (same session), which is equivalent of page >>> auto-refresh. > >> Yes, that is a reasonable state to assume at this point. Though possibly >> wrong, since it is an assumption. > >>> >>> *F5 (refresh) from the same browser:* >>> > >> NP: be aware that two fetches in a row is different form force-refresh, >> which is different from non-forced refresh. > >> One of the two refresh involved no-cache header, the other involves >> max-age=0 header. >> The double-fetch does not send either no-cache nor max-age=0. > >> Also be aware that the MSIE browser name for the button "Refresh" which >> got copied by the others is browser GUI terminology, not HTTP terminology. >> HTTP terminology uses "force-refresh" or "reload" for the two request >> header cases caused by F5 and Ctrl+F5. > Sure. In case 3 and 4 latest Google Chrome used. No MSIE bullshit, which > is not respect RFC at all. That is why I said "copied by the others". The F5-thing comes from Visual Studio hotkeys I think, it was a more recent addition. > > Anyway. This is word games. Games? no. Technical terminology is never a game. Getting it right is a critical requirement for communication and understanding the technical concepts/operations. Like I said the browser button name seems to have confused your understanding of the HTTP term usage. Which are different. > > The HTTPS object (HTTP/1.1) is absolutely sure in client and proxy > caches. Right? It was before, yes. It also is after, yes. But the two refresh and force-refresh requests placed different revalidation requirements on what Squid could do. Thus what happened was different, and that alters the tags that get logged to say what happened. > > So, why not expired object in both caches produces TCP_MISS/304? > I think the situation here is that Squid is still doing the HTTP/1.0 behaviour when the CC:no-cache request header is received. The response CC:no-cache handling was corrected, but the request handling has not been updated yet. Under HTTP/1.1 (RFC 7234 version) it should only force revalidate to happen. But in HTTP/1.0 it forced the cache to be ignored. That needs fixing. In terms of bugs this is a missing feature / enhancement issue. It is an acceptible response within HTTP/1.1 (so not major bug), but better bandwidth uses are possible. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
