[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
I do not pretend that I have seen everything.

But my personal statistics across multiple servers over they access.log
shows that TCP_MISS/304 in all cases associated with the update 
downloaded content (reload/refresh). Accordingly, the logging of this
event as a TCP_MISS seems incorrect and, consequently, leads to errors
in accounting/billing. That, in turn, can lead to a loss of money.

So, nice to have functionality for correct handling this cases.

13.10.2016 20:09, Amos Jeffries пишет:
> On 14/10/2016 2:46 a.m., Yuri Voinov wrote:
>>
>>
>>
>> 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):
>>
>
> Unknown without seeing the client request headers.
>
> There might be no content in Squid cache at the start, and due to 304
> not providing a payload none at the end either.
>
>
>>
>>>> It might be a CLIENT_IMS_UNMODIFIED or CLIENT_INM_UNMODIFIED if Squid
>>>> had codes for those cases.
>>> Ok, Squid has?
>
> Squid has TCP_MISS tag, which is used for unknown situations where a
> server was involved.
>
> 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/6OrAAoJENNXIZxhPexG1BIH/jeTUBXJZJemwUN88SU4NCy9
uRDKWbMP0kLW9WEIZnDA3V6TOrIs1u2yLxHHxN4gBPa3vmVf4qSScTZGLRcwB40E
SrdbJnOh6pHFh1qKO4+MdvpmZnjaLW5xmPXbZg8w3kXc+lwUrF3B/LqdblRSytz0
rvrgpTzjPx+SH3gAZ2MD4h7/08rEahmyxrcf3yaf8CMmlBB2Sf2SwY8BWpVROAkG
aCM/XWLssCzmb0U3Mc3STT14p3X0rjgrSni7ISXSfsxpRCT6EkRPukCQmnhm+Q/6
eiUNAVqviVbs7xNPH1oGo3ANTKoDXVKT2tIvytPZ93hBQwg2BuDdVkEIgTEx3p8=
=5YOE
-----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/4977c39b/attachment-0001.key>