<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>
<br>
<br>
13.10.2016 19:44, Yuri Voinov пишет:<br>
<span style="white-space: pre;">><br>
><br>
><br>
> 13.10.2016 19:41, Amos Jeffries пишет:<br>
> > On 14/10/2016 1:38 a.m., Yuri Voinov wrote:<br>
> >><br>
> >> -----BEGIN PGP SIGNED MESSAGE-----<br>
> >> Hash: SHA256<br>
> >><br>
> >> Hi gents.<br>
> >><br>
> >> I have very stupid question.<br>
> >><br>
> >> Look at this access.log entry:<br>
> >><br>
> >> 1476236018.506 85 192.168.100.103 TCP_MISS/304
354 GET<br>
> >> <a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/gzt/img/logo_footer.png">https://www.gazeta.ru/nm2015/gzt/img/logo_footer.png</a>
-<br>
> >> HIER_DIRECT/81.19.72.2 -<br>
> >><br>
> >> I'm see this:<br>
> >><br>
> >>
<a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/SquidFaq/SquidLogs#HTTP_status_codes">http://wiki.squid-cache.org/SquidFaq/SquidLogs#HTTP_status_codes</a><br>
> >><br>
> >> Code 304 references to RFC 2616. Ok, opens it:<br>
> >><br>
> >>
<a class="moz-txt-link-freetext" href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a><br>
> >><br>
><br>
> > The reference is outdated. Current requirements are
defined in<br>
> > <a class="moz-txt-link-rfc2396E" href="https://tools.ietf.org/html/rfc7232#section-4.1"><https://tools.ietf.org/html/rfc7232#section-4.1></a><br>
><br>
> > ...<br>
> >><br>
> >> According to RFC 2616, it comes from client's
browser cache, make<br>
> >> revalidation, discover content no changed and return
304 code.<br>
> >><br>
> >> So, it must means (exactly) CLIENT_HIT, right?<br>
> >><br>
><br>
> > No. Squid does not receive transactions that would match
the meaning of<br>
> > the tags CLIENT_HIT.<br>
> Ok.<br>
><br>
><br>
><br>
> >> My question is:<br>
> >><br>
> >> *Why Squid register this as TCP_MISS/304 in
access.log, when logically<br>
> >> expect TCP_CLIENT_HIT/304?*<br>
><br>
> > This is a MISS on the Squid cache. A 304 from the server
delivered to<br>
> > the client.<br>
> Ok, 304 delivered. But content - not, right? So, this is HIT
- even not<br>
> Squid's hit, yes?</span><br>
In agreement with this
(<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7232#page-18">https://tools.ietf.org/html/rfc7232#page-18</a>):<br>
<br>
Since the goal of a 304 response is to minimize information
transfer<br>
when the recipient already has one or more cached
representations, a<br>
sender SHOULD NOT generate representation metadata other than the<br>
above listed fields unless said metadata exists for the purpose
of<br>
guiding cache updates (e.g., Last-Modified might be useful if the<br>
response does not have an ETag field).<br>
<br>
Requirements on a cache that receives a 304 response are defined
in<br>
Section 4.3.4 of [RFC7234]
<a class="moz-txt-link-rfc2396E" href="https://tools.ietf.org/html/rfc7234#section-4.3.4"><https://tools.ietf.org/html/rfc7234#section-4.3.4></a>. If the
conditional request originated<br>
with an outbound client, such as a user agent with its own cache<br>
sending a conditional GET to a shared proxy, then the proxy
SHOULD<br>
forward the 304 response to that client.<br>
<br>
A 304 response cannot contain a message-body; it is always
terminated<br>
by the first empty line after the header fields.<br>
<br>
<br>
<span style="white-space: pre;">><br>
><br>
> > It might be a CLIENT_IMS_UNMODIFIED or
CLIENT_INM_UNMODIFIED if Squid<br>
> > had codes for those cases.<br>
> Ok, Squid has?<br>
><br>
><br>
> > Amos<br>
><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>
iQEcBAEBCAAGBQJX/5A/AAoJENNXIZxhPexG3NYIAL9pmUn4uAUt2ce9aPu8q/kA
<br>
Yeyn5qoCzEhY4Z0bqLFWfyECcQVU1MrcAhhhuRkdPI9zrfVIbF4oa2En4r9jTrUb
<br>
nhACmAAq64cYjOIYA9VYzkmiaaPF/ZzSnw+nF9uAwwfUOYP+L0Clg+D4KoywcAqG
<br>
0XAOWSasxrc70kFxid17NSMs0/kIIxEek6qhMDbBFKedZoucygIPfgGRX8+cEBQV
<br>
8aRdU/M4+HfSNk9sRFcTGUdA44K54z8mOwUDn4axW44M3AOAkDVn1cctaVvYgCLl
<br>
NK4Umq0pc0AoF4YoxRRbuXxA6YOvN1CtIhbW8tcYH32Y4dzzcHRdFU9A6kxj8Bw=
<br>
=Aulv
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>