|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Well. Let's made clean, easy to reproduce example. Let's take one PC behind proxy. Let's clean up any browser's caches. Let's reboot it for experiment clarity. Let's take two URLs. One for HTTP and the same for HTTPS. Simple static image 200 Kb in size. http://www.opennet.ru/img/carbonsoft1.gif https://www.opennet.ru/img/carbonsoft1.gif Let's run Chrome and Firefox on selected PC. Let's load both object's in browser's cache. Let's verify both in proxy cache: 1476449165.101 537 192.168.100.103 TCP_HIT/200 210951 GET http://www.opennet.ru/img/carbonsoft1.gif - HIER_NONE/- image/gif HTTP and HIT. Exactly. All the same, but via HTTPS: 1476449299.999 470 192.168.100.103 TCP_MISS/200 210857 GET https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 image/gif First load. MISS. It's ok. Second load. Same PC, Firefox: 1476449352.792 105 192.168.100.103 TCP_HIT/200 210864 GET https://www.opennet.ru/img/carbonsoft1.gif - HIER_NONE/- image/gif HTTPS and HIT. It's ok. As expected. Same Firefox, F5, refresh: 1476449412.235 102 192.168.100.103 TCP_MISS/304 294 GET https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 - Same Chrome, F5, refresh (note: object on proxy cache, and in both browsers caches): 1476449477.621 87 192.168.100.103 TCP_MISS/304 294 GET https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 - Let's see on headers: root @ khorne /tmp # wget -S http://www.opennet.ru/img/carbonsoft1.gif - --2016-10-14 18:51:56-- http://www.opennet.ru/img/carbonsoft1.gif Connecting to 127.0.0.1:3128... connected. Proxy request sent, awaiting response... HTTP/1.1 200 OK Server: nginx/1.0.9 Date: Tue, 11 Oct 2016 17:28:11 GMT Content-Type: image/gif Content-Length: 210501 Last-Modified: Mon, 05 Sep 2016 12:35:00 GMT Expires: Thu, 10 Nov 2016 17:28:11 GMT Cache-Control: max-age=2592000 Accept-Ranges: bytes Age: 242631 Warning: 113 khorne (squid) This cache hit is still fresh and more than 1 day old X-Cache: HIT from khorne X-Cache-Lookup: HIT from khorne:3128 Connection: keep-alive Length: 210501 (206K) [image/gif] Saving to: 'carbonsoft1.gif' carbonsoft1.gif 100%[==================>] 205.57K --.-KB/s in 0.001s 2016-10-14 18:51:56 (298 MB/s) - 'carbonsoft1.gif' saved [210501/210501] root @ khorne /tmp # wget -S https://www.opennet.ru/img/carbonsoft1.gif - --2016-10-14 18:52:20-- https://www.opennet.ru/img/carbonsoft1.gif Connecting to 127.0.0.1:3128... connected. Proxy request sent, awaiting response... HTTP/1.1 200 OK Server: nginx/1.0.9 Date: Fri, 14 Oct 2016 12:48:23 GMT Content-Type: image/gif Content-Length: 210501 Last-Modified: Mon, 05 Sep 2016 12:35:00 GMT Expires: Sun, 13 Nov 2016 12:48:23 GMT Cache-Control: max-age=2592000 Accept-Ranges: bytes Age: 241 X-Cache: HIT from khorne X-Cache-Lookup: HIT from khorne:3128 Connection: keep-alive Length: 210501 (206K) [image/gif] Saving to: 'carbonsoft1.gif.1' carbonsoft1.gif.1 100%[==================>] 205.57K 398KB/s in 0.5s 2016-10-14 18:52:21 (398 KB/s) - 'carbonsoft1.gif.1' saved [210501/210501] Yes, both HTTP and HTTPS in proxy cache, right? Both is HTTP/1.1, right? All headers the same, no cache preventing. Let's refresh from Chrome HTTP object: 1476449587.276 111 192.168.100.103 TCP_REFRESH_UNMODIFIED/304 301 GET http://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 - Request size = 301 TCP_REFRESH_UNMODIFIED. As expected, ok. Let's refresh HTTPS from same chrome: 1476449697.991 129 192.168.100.103 TCP_MISS/304 294 GET https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 - Request size = 294 TCP_MISS/304. You can easy to reproduce this by youself. Squid 3.5.22. The question is the same. Latest example must be TCP_REFRESH_UNMODIFIED. I see no reason why it should be different tnan HTTP object versions. Squid's begaviour must be the same, as described in RFC. Right? Because there is absolutely no any reason for this example, why it must be different. Agreed? All the rest is sophistry and does not explain anything. 14.10.2016 18:36, Yuri Voinov пишет: > > > > 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. > > Anyway. This is word games. > > The HTTPS object (HTTP/1.1) is absolutely sure in client and proxy > caches. Right? > > So, why not expired object in both caches produces TCP_MISS/304? > > > > >> 1476443997.252 96 192.168.100.103 TCP_MISS/304 353 GET > >> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js - > >> HIER_DIRECT/81.19.72.0 - > >> > >> Here is it. Object in proxy cache, in client cache, revalidation is ok - > >> object not changed. It must be TCP_REFRESH_UNMODIFIED, and this tag > >> we've got with HTTP object via browser. > > > No. I think you have confused the GUI button name with the Squid log tag > > name. > > REFRESH tag occurs on revalidation transactions. The F5 (aka > > "forced-refresh") can lead to that. > > The Ctrl+F5 (aka. "reload") can only lead to MISS (aks reload, re-fetch, > > "discard cached contents"). > > > When a browser send no-cache the cached content must not be used, but > > can be updated by the reply that comes back. > > > When the browser sends max-age=0, the cached contents *can* be used > > provided they meet the 0sec old criteria (ie revalidate, then use the > > resulting cache object). > > >> > >> /But shit! HTTPS goes TCP_MISS/304! We're expected to get > >> TCP_REFRESH_UNMODIFIED/304! Because this is refresh operation, we're > >> sure object in both caches - proxy and client, revalidation is ok, but > >> this marks as MISS./ > > > Your expectation was fooled by the browser mis-naming of things. > > >> > >> Why HTTP refresh goes with TCP_REFRESH_UNMODIFIED, and the same object > >> via HTTPS goes with TCP_MISS? As shown above, object has no headers > >> preventing caching. > > > HTTP is not relevant for the reason stated above. What your test has > > done is fetch the same https:// URL in three different ways and seen > > three different log entries result from that. > > > Whether they were the right responses is unknown. But at least they were > > different. I would be more worried if they were the same. > > >> > >> Is it bug or feature? Because of, when site goes under HTTPS, it will > >> has lower hit with the same content. It seems wrong. > > > I hope the above clarifies the situation. There may or may not be bugs > > involved, but this test does not demonstrate any that I can see. > > > It also does not demonstrate any difference in HIT with HTTP vs HTTPS. > > In fact it demonstrates that HTTPS is getting HITs. > > > Amos > > _______________________________________________ > > squid-users mailing list > > squid-users@xxxxxxxxxxxxxxxxxxxxx > > http://lists.squid-cache.org/listinfo/squid-users > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYANctAAoJENNXIZxhPexGN4MH/R9W5fIyVU1rAQN8VMutU5an rZ+GZoiUmKWFGxs5yFEJzpvGrarZjJyJO3RCfEYn/sFLxCAEa4vrUKL2x8KyUycC m/0TYQmDq+H264mcKrAX0GG/6yNCodh3aZfNT9EFb0tHKRxPeBt8VfD7Qu4dbv3V SMgysccNNLGbSK4zWEUF78luWsvc0Y+5LRsEbjAkBKpD4V9yG6gj5XC0tFiEqyvy uNVdCq5r57mXmoeUAlGBEnAHXRusxjppPM2ySVSYGhib+R9AdKZVCEPlgzcmGXbJ pj7YwIt+UBs5lkmRCRH6jC2Xzie17bFBneEqkF+xsmfKr+h51FMzn2MVCUcppVA= =p1yH -----END PGP SIGNATURE----- |
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
