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