-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 13.10.2016 21:02, Yuri Voinov пишет: > > > > 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. A bit disagree. When we seen TCP_MISS/200 with reply size above headers size - we can be sure content tresspasses proxy first time and this is clean MISS. When we seen ??????/304 with only headers - most probably content behind proxy already and this is CLIENT_IMS_HIT observed. Yes, of course, we don't know is this content really in client cache. But this is don't care - proxy shared cache contains not modified copy of content. Right? > > > 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@xxxxxxxxxxxxxxxxxxxxx > > http://lists.squid-cache.org/listinfo/squid-users > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX/8nBAAoJENNXIZxhPexG6O4H/RSPqYtUJc/c13sENtup86gH 5tg3n1QeU5xLOF0k+osexcvAwf/McuFux4aVN92yJw6F2A3PvQSksdDSo0PVNNZZ tHQAotiqdxf2NvwU+ZTP91UxYpl8UhNBtWYanWLsrH4taTPznKYmvCQ/TNwTWFqB R9Wa8KTN1OqX7AK3uRYiCdhzjO/+wwg9p+1RA+YaVNJGBuA/Gp2ANXkeZsgZK4Nn pDfmGP/Jg2TmaRgnPe8U4bZnkYzLcoOaIy/ytM8ePxJiVlHyEBMohjrfZUN6/Nez 9GwwA3mRl5MH8DsDz8Ro/7D5DHirnVzfWdGBMFzk12kL/SF7uR/XjvRyohAqtps= =mIPv -----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