[squid-users] TCP_MISS/304 question

[Yuri Voinov]

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


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.
In given example I know exactly content already in client cache and
Squid's too. This record occurs due to web-page, contains auto-refresh
code/pragma. And does periodically refresh.

Well, is it possible to make this known? We're on proxy between client
and web-server. So, it can be easy - сode 304 is immediately after the
reload/refresh query by the same client.

It is not possible to pre-remember that it sent the client in the header
- or a request for an update - and create the correct tag? And not on
the principle of "We broke to determine that it is - so that we log this
as TCP_MISS."

It seems to me, such behavior would be more appropriate, and more than
would be consistent with RFC.

Right?
>
>
>
>>
>>>> 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/6IcAAoJENNXIZxhPexG+vcH/1nusCNTLM0QR9j8iun6dRnS
h/zD1bNMDJB4EfWr6ZAfUbocoRuYvsv6TRXOu9mTvO0fSTYBd6q3hc97y3en2ivY
Iw0yLuKb9pPxEF1UdjgGKgy9Ibyn4mdhoMZ7uRRDvZx6tvg0JcaF165Yw6osKC6L
0fZXO2fwklwHUC8eGl437yV/HVXv9TWX99VOcKZjtgLe1tpHq2JmJhYp3uv8DUXV
/HMKx0ByxGjZsgdJ9pcP2YMOdZKPA4K3jxJmSf1XuwQH/Mab5Arbx/5DhXUw/7On
+FtdReEc40IN/xwi6zxMERuU8XRlQbnFjCOH+KdVV8mPzS89xj13IL59GUux7+I=
=dEtK
-----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/d0cf5e7b/attachment.key>