[squid-users] TCP_MISS/304 question
Yuri Voinov
yvoinov at gmail.com
Fri Oct 14 13:01:34 UTC 2016
-----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 at lists.squid-cache.org
> > 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-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161014/1e45a301/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161014/1e45a301/attachment-0001.key>
More information about the squid-users
mailing list