[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-----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

and read:

"


      10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line
after the header fields.

The response MUST include the following header fields:

      - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients
add their own Date to any response received without one (as already
specified by [RFC 2068], section 14.19
<https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19>),
caches will operate correctly.

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers. Otherwise
(i.e., the conditional GET used a weak validator), the response MUST NOT
include other entity-headers; this prevents inconsistencies between
cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the
conditional.

If a cache uses a received 304 response to update a cache entry, the
cache MUST update the entry to reflect any new field values given in the
response.

"

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?

My question is:

*Why Squid register this as TCP_MISS/304 in access.log, when logically
expect TCP_CLIENT_HIT/304?*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJX/4ApAAoJENNXIZxhPexGUO8H/iSYKoMpk2nis3mWF/0Vg58y
2/3+lJaf71RspA8WQ23m4JgqhnmfXF8AlMr/wgvaOCMRTpNumKfL3zhnKd3s4tmq
wXvG562PVHhdBO9gnFK+75PYo1xMe5jdbAHMr+XRzv0ylnBE04rNV+tbpSrRTH2Z
BwZrlDi/Y5UmcPF9zrFIy/6umoeDBkKJHpAlmVwD0krWNmgn2ScquPIQZpoqOgtR
yNGMS7WCAhOF7HGQMaHPsW6RzqwKzWGs6L6pg6CbaE780suncHJqQkq+sY8NgB4k
jZmgH579NiH9f+aVwAjIE7IN+aOv/0XWnT3YfFgeFba03JWu8c5e/oHeFFzhKRE=
=uXt1
-----END PGP SIGNATURE-----

-------------- 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/199b0bb1/attachment.key>