[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-----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 at lists.squid-cache.org
> > 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-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161013/b6604844/attachment.html>
-------------- 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/b6604844/attachment.key>