<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
Well. Let's made clean, easy to reproduce example.<br>
<br>
Let's take one PC behind proxy. Let's clean up any browser's caches.
Let's reboot it for experiment clarity.<br>
<br>
Let's take two URLs. One for HTTP and the same for HTTPS. Simple
static image 200 Kb in size.<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.opennet.ru/img/carbonsoft1.gif">http://www.opennet.ru/img/carbonsoft1.gif</a><br>
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a><br>
<br>
Let's run Chrome and Firefox on selected PC.<br>
<br>
Let's load both object's in browser's cache. Let's verify both in
proxy cache:<br>
<br>
1476449165.101 537 192.168.100.103 TCP_HIT/200 210951 GET
<a class="moz-txt-link-freetext" href="http://www.opennet.ru/img/carbonsoft1.gif">http://www.opennet.ru/img/carbonsoft1.gif</a> - HIER_NONE/- image/gif<br>
<br>
HTTP and HIT. Exactly.<br>
<br>
All the same, but via HTTPS:<br>
<br>
1476449299.999 470 192.168.100.103 TCP_MISS/200 210857 GET
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a> -
HIER_DIRECT/81.95.33.238 image/gif<br>
<br>
First load. MISS. It's ok.<br>
<br>
Second load. Same PC, Firefox:<br>
<br>
1476449352.792 105 192.168.100.103 TCP_HIT/200 210864 GET
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a> - HIER_NONE/- image/gif<br>
<br>
HTTPS and HIT. It's ok. As expected.<br>
<br>
Same Firefox, F5, refresh:<br>
<br>
1476449412.235 102 192.168.100.103 TCP_MISS/304 294 GET
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a> -
HIER_DIRECT/81.95.33.238 -<br>
<br>
Same Chrome, F5, refresh (note: object on proxy cache, and in both
browsers caches):<br>
<br>
1476449477.621 87 192.168.100.103 TCP_MISS/304 294 GET
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a> -
HIER_DIRECT/81.95.33.238 -<br>
<br>
Let's see on headers:<br>
<br>
<br>
root @ khorne /tmp # wget -S
<a class="moz-txt-link-freetext" href="http://www.opennet.ru/img/carbonsoft1.gif">http://www.opennet.ru/img/carbonsoft1.gif</a><br>
- --2016-10-14 18:51:56-- <a class="moz-txt-link-freetext" href="http://www.opennet.ru/img/carbonsoft1.gif">http://www.opennet.ru/img/carbonsoft1.gif</a><br>
Connecting to 127.0.0.1:3128... connected.<br>
Proxy request sent, awaiting response...<br>
HTTP/1.1 200 OK<br>
Server: nginx/1.0.9<br>
Date: Tue, 11 Oct 2016 17:28:11 GMT<br>
Content-Type: image/gif<br>
Content-Length: 210501<br>
Last-Modified: Mon, 05 Sep 2016 12:35:00 GMT<br>
Expires: Thu, 10 Nov 2016 17:28:11 GMT<br>
Cache-Control: max-age=2592000<br>
Accept-Ranges: bytes<br>
Age: 242631<br>
Warning: 113 khorne (squid) This cache hit is still fresh and more
than 1 day old<br>
X-Cache: HIT from khorne<br>
X-Cache-Lookup: HIT from khorne:3128<br>
Connection: keep-alive<br>
Length: 210501 (206K) [image/gif]<br>
Saving to: 'carbonsoft1.gif'<br>
<br>
carbonsoft1.gif 100%[==================>] 205.57K
--.-KB/s in 0.001s<br>
<br>
2016-10-14 18:51:56 (298 MB/s) - 'carbonsoft1.gif' saved
[210501/210501]<br>
<br>
root @ khorne /tmp # wget -S
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a><br>
- --2016-10-14 18:52:20--
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a><br>
Connecting to 127.0.0.1:3128... connected.<br>
Proxy request sent, awaiting response...<br>
HTTP/1.1 200 OK<br>
Server: nginx/1.0.9<br>
Date: Fri, 14 Oct 2016 12:48:23 GMT<br>
Content-Type: image/gif<br>
Content-Length: 210501<br>
Last-Modified: Mon, 05 Sep 2016 12:35:00 GMT<br>
Expires: Sun, 13 Nov 2016 12:48:23 GMT<br>
Cache-Control: max-age=2592000<br>
Accept-Ranges: bytes<br>
Age: 241<br>
X-Cache: HIT from khorne<br>
X-Cache-Lookup: HIT from khorne:3128<br>
Connection: keep-alive<br>
Length: 210501 (206K) [image/gif]<br>
Saving to: 'carbonsoft1.gif.1'<br>
<br>
carbonsoft1.gif.1 100%[==================>] 205.57K
398KB/s in 0.5s <br>
<br>
2016-10-14 18:52:21 (398 KB/s) - 'carbonsoft1.gif.1' saved
[210501/210501]<br>
<br>
Yes, both HTTP and HTTPS in proxy cache, right? Both is HTTP/1.1,
right? All headers the same, no cache preventing.<br>
<br>
Let's refresh from Chrome HTTP object:<br>
<br>
1476449587.276 111 192.168.100.103 TCP_REFRESH_UNMODIFIED/304 301
GET <a class="moz-txt-link-freetext" href="http://www.opennet.ru/img/carbonsoft1.gif">http://www.opennet.ru/img/carbonsoft1.gif</a> -
HIER_DIRECT/81.95.33.238 -<br>
<br>
Request size = 301<br>
<br>
TCP_REFRESH_UNMODIFIED. As expected, ok.<br>
<br>
Let's refresh HTTPS from same chrome:<br>
<br>
1476449697.991 129 192.168.100.103 TCP_MISS/304 294 GET
<a class="moz-txt-link-freetext" href="https://www.opennet.ru/img/carbonsoft1.gif">https://www.opennet.ru/img/carbonsoft1.gif</a> -
HIER_DIRECT/81.95.33.238 -<br>
<br>
Request size = 294<br>
<br>
TCP_MISS/304.<br>
<br>
You can easy to reproduce this by youself. Squid 3.5.22.<br>
<br>
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.<br>
<br>
Agreed?<br>
<br>
All the rest is sophistry and does not explain anything.<br>
<br>
14.10.2016 18:36, Yuri Voinov пишет:<br>
<span style="white-space: pre;">><br>
><br>
><br>
> 14.10.2016 18:30, Amos Jeffries пишет:<br>
> > On 15/10/2016 12:34 a.m., Yuri Voinov wrote:<br>
> >><br>
> >> A bit more details.<br>
> >><br>
> >> This is 4 transactions in chronological order. Two
from wget -S and two<br>
> >> from same PC via browser for the same URL:<br>
> >><br>
> >> *root @ khorne /tmp # wget -S<br>
> >>
<a class="moz-txt-link-freetext" href="http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*">http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*</a><br>
> >> --2016-10-14 17:18:05--<br>
> >> <a class="moz-txt-link-freetext" href="http://www.gazeta.ru/nm2015/js/gazeta.media.query.js">http://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a><br>
> >> Connecting to 127.0.0.1:3128... connected.<br>
> >> Proxy request sent, awaiting response...<br>
> >> HTTP/1.1 301 Moved Permanently<br>
> >> Server: nginx<br>
> >> Date: Fri, 14 Oct 2016 11:18:07 GMT<br>
> >> Content-Type: text/html<br>
> >> Content-Length: 178<br>
> >> Location:
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a><br>
> >> X-Cache: MISS from khorne<br>
> >> X-Cache-Lookup: MISS from khorne:3128<br>
> >> Connection: keep-alive<br>
> >> Location:
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a><br>
> [following]<br>
> >> --2016-10-14 17:18:07--<br>
> >>
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a><br>
><br>
> > Notice how the Location header made wget fetch send a
second fetch to<br>
> > *actually* load an HTTPS object.<br>
><br>
> > This means your use of HTTP is irrelevant. HTTP just
results in an 301<br>
> > response. That is the end of the HTTP...<br>
><br>
> Location:
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a><br>
><br>
> This is no matter.<br>
><br>
><br>
><br>
> >> Connecting to 127.0.0.1:3128... connected.<br>
> >> Proxy request sent, awaiting response...<br>
> >> HTTP/1.1 200 OK<br>
> >> Server: nginx<br>
> >> Date: Fri, 14 Oct 2016 10:45:57 GMT<br>
> >> Content-Type: application/javascript;
charset=windows-1251<br>
> >> Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT<br>
> >> ETag: W/"cdf370-758-52351a306ac80"<br>
> >> Cache-Control: max-age=3600<br>
> >> Expires: Fri, 14 Oct 2016 11:45:57 GMT<br>
> >> Access-Control-Allow-Origin: *<br>
> >> Age: 1930<br>
> >> X-Cache: HIT from khorne<br>
> >> X-Cache-Lookup: HIT from khorne:3128<br>
> >> Transfer-Encoding: chunked<br>
> >> Connection: keep-alive<br>
> >> Length: unspecified [application/javascript]<br>
> >> Saving to: 'gazeta.media.query.js'<br>
> >><br>
> >> gazeta.media.query. [ <=>
] 1.84K --.-KB/s in<br>
> >> 0s <br>
> >><br>
> >> 2016-10-14 17:18:07 (138 MB/s) -
'gazeta.media.query.js' saved [1880]<br>
> >><br>
> >> /HTTP object in cache and HIT./<br>
><br>
> > No. *HTTPS* object in cache and HIT.<br>
> Oh, mistype. Let it be HTTPS and HIT.<br>
><br>
><br>
><br>
> >> *<br>
> >> **root @ khorne /tmp # wget -S<br>
> >>
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*</a><br>
> >> --2016-10-14 17:18:30--<br>
> >>
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a><br>
> >> Connecting to 127.0.0.1:3128... connected.<br>
> >> Proxy request sent, awaiting response...<br>
> >> HTTP/1.1 200 OK<br>
> >> Server: nginx<br>
> >> Date: Fri, 14 Oct 2016 10:45:57 GMT<br>
> >> Content-Type: application/javascript;
charset=windows-1251<br>
> >> Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT<br>
> >> ETag: W/"cdf370-758-52351a306ac80"<br>
> >> Cache-Control: max-age=3600<br>
> >> Expires: Fri, 14 Oct 2016 11:45:57 GMT<br>
> >> Access-Control-Allow-Origin: *<br>
> >> Age: 1953<br>
> >> X-Cache: HIT from khorne<br>
> >> X-Cache-Lookup: HIT from khorne:3128<br>
> >> Transfer-Encoding: chunked<br>
> >> Connection: keep-alive<br>
> >> Length: unspecified [application/javascript]<br>
> >> Saving to: 'gazeta.media.query.js.1'<br>
> >><br>
> >> gazeta.media.query. [ <=>
] 1.84K --.-KB/s in<br>
> >> 0s <br>
> >><br>
> >> 2016-10-14 17:18:30 (120 MB/s) -
'gazeta.media.query.js.1' saved [1880]<br>
> >><br>
> >> /HTTPS object in cache and HIT too./<br>
><br>
> > No. Same HTTPS object from test #1 is still in cache and
still being HIT.<br>
><br>
> >><br>
> >> This is ok.<br>
><br>
> > Uh, not if you are going to interpret the first test as
being an HTTP<br>
> > object in cache.<br>
><br>
> > What this tells is that fetching an HTTPS object twice
in a row will<br>
> > produce a HIT.<br>
> Yes. Let it be.<br>
><br>
><br>
> >><br>
> >> *Ctrl+F5 (force reload) from browser:*<br>
> >><br>
> >> 1476443947.419 92 192.168.100.103 TCP_MISS/200
2323 GET<br>
> >>
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a> -<br>
> >> HIER_DIRECT/81.19.72.0 application/javascript<br>
> >><br>
> >> MISS - it is ok too, client browser sends no-cache.<br>
><br>
> > Did you check the client request to verify that
"no-cache" statement?<br>
> Yes.<br>
><br>
><br>
> >><br>
> >> At this point we sure object in cache, right? Both
in proxy cache and in<br>
> >> client cache (client is the same in attempt 3 and
4). Now - refresh from<br>
> >> browser on the same page (same session), which is
equivalent of page<br>
> >> auto-refresh.<br>
><br>
> > Yes, that is a reasonable state to assume at this point.
Though possibly<br>
> > wrong, since it is an assumption.<br>
><br>
> >><br>
> >> *F5 (refresh) from the same browser:*<br>
> >><br>
><br>
> > NP: be aware that two fetches in a row is different form
force-refresh,<br>
> > which is different from non-forced refresh.<br>
><br>
> > One of the two refresh involved no-cache header, the
other involves<br>
> > max-age=0 header.<br>
> > The double-fetch does not send either no-cache nor
max-age=0.<br>
><br>
> > Also be aware that the MSIE browser name for the button
"Refresh" which<br>
> > got copied by the others is browser GUI terminology, not
HTTP terminology.<br>
> > HTTP terminology uses "force-refresh" or "reload" for
the two request<br>
> > header cases caused by F5 and Ctrl+F5.<br>
> Sure. In case 3 and 4 latest Google Chrome used. No MSIE
bullshit, which<br>
> is not respect RFC at all.<br>
><br>
> Anyway. This is word games.<br>
><br>
> The HTTPS object (HTTP/1.1) is absolutely sure in client and
proxy<br>
> caches. Right?<br>
><br>
> So, why not expired object in both caches produces
TCP_MISS/304?<br>
><br>
><br>
><br>
> >> 1476443997.252 96 192.168.100.103 TCP_MISS/304
353 GET<br>
> >>
<a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/js/gazeta.media.query.js">https://www.gazeta.ru/nm2015/js/gazeta.media.query.js</a> -<br>
> >> HIER_DIRECT/81.19.72.0 -<br>
> >><br>
> >> Here is it. Object in proxy cache, in client cache,
revalidation is ok -<br>
> >> object not changed. It must be
TCP_REFRESH_UNMODIFIED, and this tag<br>
> >> we've got with HTTP object via browser.<br>
><br>
> > No. I think you have confused the GUI button name with
the Squid log tag<br>
> > name.<br>
> > REFRESH tag occurs on revalidation transactions. The F5
(aka<br>
> > "forced-refresh") can lead to that.<br>
> > The Ctrl+F5 (aka. "reload") can only lead to MISS (aks
reload, re-fetch,<br>
> > "discard cached contents").<br>
><br>
> > When a browser send no-cache the cached content must not
be used, but<br>
> > can be updated by the reply that comes back.<br>
><br>
> > When the browser sends max-age=0, the cached contents
*can* be used<br>
> > provided they meet the 0sec old criteria (ie revalidate,
then use the<br>
> > resulting cache object).<br>
><br>
> >><br>
> >> /But shit! HTTPS goes TCP_MISS/304! We're expected
to get<br>
> >> TCP_REFRESH_UNMODIFIED/304! Because this is refresh
operation, we're<br>
> >> sure object in both caches - proxy and client,
revalidation is ok, but<br>
> >> this marks as MISS./<br>
><br>
> > Your expectation was fooled by the browser mis-naming of
things.<br>
><br>
> >><br>
> >> Why HTTP refresh goes with TCP_REFRESH_UNMODIFIED,
and the same object<br>
> >> via HTTPS goes with TCP_MISS? As shown above, object
has no headers<br>
> >> preventing caching.<br>
><br>
> > HTTP is not relevant for the reason stated above. What
your test has<br>
> > done is fetch the same <a class="moz-txt-link-freetext" href="https://">https://</a> URL in three different
ways and seen<br>
> > three different log entries result from that.<br>
><br>
> > Whether they were the right responses is unknown. But at
least they were<br>
> > different. I would be more worried if they were the
same.<br>
><br>
> >><br>
> >> Is it bug or feature? Because of, when site goes
under HTTPS, it will<br>
> >> has lower hit with the same content. It seems wrong.<br>
><br>
> > I hope the above clarifies the situation. There may or
may not be bugs<br>
> > involved, but this test does not demonstrate any that I
can see.<br>
><br>
> > It also does not demonstrate any difference in HIT with
HTTP vs HTTPS.<br>
> > In fact it demonstrates that HTTPS is getting HITs.<br>
><br>
> > Amos<br>
> > _______________________________________________<br>
> > squid-users mailing list<br>
> > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJYANctAAoJENNXIZxhPexGN4MH/R9W5fIyVU1rAQN8VMutU5an
<br>
rZ+GZoiUmKWFGxs5yFEJzpvGrarZjJyJO3RCfEYn/sFLxCAEa4vrUKL2x8KyUycC
<br>
m/0TYQmDq+H264mcKrAX0GG/6yNCodh3aZfNT9EFb0tHKRxPeBt8VfD7Qu4dbv3V
<br>
SMgysccNNLGbSK4zWEUF78luWsvc0Y+5LRsEbjAkBKpD4V9yG6gj5XC0tFiEqyvy
<br>
uNVdCq5r57mXmoeUAlGBEnAHXRusxjppPM2ySVSYGhib+R9AdKZVCEPlgzcmGXbJ
<br>
pj7YwIt+UBs5lkmRCRH6jC2Xzie17bFBneEqkF+xsmfKr+h51FMzn2MVCUcppVA=
<br>
=p1yH
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>