-----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-----
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
