[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


13.10.2016 19:44, Yuri Voinov пишет:
>
>
>
> 13.10.2016 19:41, Amos Jeffries пишет:
> > On 14/10/2016 1:38 a.m., Yuri Voinov wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Hi gents.
> >>
> >> I have very stupid question.
> >>
> >> Look at this access.log entry:
> >>
> >> 1476236018.506     85 192.168.100.103 TCP_MISS/304 354 GET
> >> https://www.gazeta.ru/nm2015/gzt/img/logo_footer.png -
> >> HIER_DIRECT/81.19.72.2 -
> >>
> >> I'm see this:
> >>
> >> http://wiki.squid-cache.org/SquidFaq/SquidLogs#HTTP_status_codes
> >>
> >> Code 304 references to RFC 2616. Ok, opens it:
> >>
> >> https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> >>
>
> > The reference is outdated. Current requirements are defined in
> > <https://tools.ietf.org/html/rfc7232#section-4.1>
>
> > ...
> >>
> >> According to RFC 2616, it comes from client's browser cache, make
> >> revalidation, discover content no changed and return 304 code.
> >>
> >> So, it must means (exactly) CLIENT_HIT, right?
> >>
>
> > No. Squid does not receive transactions that would match the meaning of
> > the tags CLIENT_HIT.
> Ok.
>
>
>
> >> My question is:
> >>
> >> *Why Squid register this as TCP_MISS/304 in access.log, when logically
> >> expect TCP_CLIENT_HIT/304?*
>
> > This is a MISS on the Squid cache. A 304 from the server delivered to
> > the client.
> Ok, 304 delivered. But content - not, right? So, this is HIT - even not
> Squid's hit, yes?
In agreement with this (https://tools.ietf.org/html/rfc7232#page-18):

 Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations, a
   sender SHOULD NOT generate representation metadata other than the
   above listed fields unless said metadata exists for the purpose of
   guiding cache updates (e.g., Last-Modified might be useful if the
   response does not have an ETag field).

   Requirements on a cache that receives a 304 response are defined in
   Section 4.3.4 of [RFC7234]
<https://tools.ietf.org/html/rfc7234#section-4.3.4>.  If the conditional
request originated
   with an outbound client, such as a user agent with its own cache
   sending a conditional GET to a shared proxy, then the proxy SHOULD
   forward the 304 response to that client.

   A 304 response cannot contain a message-body; it is always terminated
   by the first empty line after the header fields.


>
>
> > It might be a CLIENT_IMS_UNMODIFIED or CLIENT_INM_UNMODIFIED if Squid
> > had codes for those cases.
> Ok, Squid has?
>
>
> > 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
 
iQEcBAEBCAAGBQJX/5A/AAoJENNXIZxhPexG3NYIAL9pmUn4uAUt2ce9aPu8q/kA
Yeyn5qoCzEhY4Z0bqLFWfyECcQVU1MrcAhhhuRkdPI9zrfVIbF4oa2En4r9jTrUb
nhACmAAq64cYjOIYA9VYzkmiaaPF/ZzSnw+nF9uAwwfUOYP+L0Clg+D4KoywcAqG
0XAOWSasxrc70kFxid17NSMs0/kIIxEek6qhMDbBFKedZoucygIPfgGRX8+cEBQV
8aRdU/M4+HfSNk9sRFcTGUdA44K54z8mOwUDn4axW44M3AOAkDVn1cctaVvYgCLl
NK4Umq0pc0AoF4YoxRRbuXxA6YOvN1CtIhbW8tcYH32Y4dzzcHRdFU9A6kxj8Bw=
=Aulv
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161013/d924efcd/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/20161013/d924efcd/attachment-0001.key>