<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    <br>
    <br>
    13.10.2016 21:02, Yuri Voinov пишет:<br>
    <span style="white-space: pre;">><br>
      ><br>
      ><br>
      > 13.10.2016 20:09, Amos Jeffries пишет:<br>
      > > On 14/10/2016 2:46 a.m., Yuri Voinov wrote:<br>
      > >><br>
      > >><br>
      > >><br>
      > >> 13.10.2016 19:44, Yuri Voinov пишет:<br>
      > >><br>
      > >><br>
      > >><br>
      > >>> 13.10.2016 19:41, Amos Jeffries пишет:<br>
      > >>>> On 14/10/2016 1:38 a.m., Yuri Voinov wrote:<br>
      > >>>>><br>
      > >>>>> -----BEGIN PGP SIGNED MESSAGE-----<br>
      > >>>>> Hash: SHA256<br>
      > >>>>><br>
      > >>>>> Hi gents.<br>
      > >>>>><br>
      > >>>>> I have very stupid question.<br>
      > >>>>><br>
      > >>>>> Look at this access.log entry:<br>
      > >>>>><br>
      > >>>>> 1476236018.506     85 192.168.100.103
      TCP_MISS/304 354 GET<br>
      > >>>>>
      <a class="moz-txt-link-freetext" href="https://www.gazeta.ru/nm2015/gzt/img/logo_footer.png">https://www.gazeta.ru/nm2015/gzt/img/logo_footer.png</a> -<br>
      > >>>>> HIER_DIRECT/81.19.72.2 -<br>
      > >>>>><br>
      > >>>>> I'm see this:<br>
      > >>>>><br>
      > >>>>>
      <a class="moz-txt-link-freetext" href="http://wiki.squid-cache.org/SquidFaq/SquidLogs#HTTP_status_codes">http://wiki.squid-cache.org/SquidFaq/SquidLogs#HTTP_status_codes</a><br>
      > >>>>><br>
      > >>>>> Code 304 references to RFC 2616. Ok,
      opens it:<br>
      > >>>>><br>
      > >>>>>
      <a class="moz-txt-link-freetext" href="https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a><br>
      > >>>>><br>
      > >><br>
      > >>>> The reference is outdated. Current
      requirements are defined in<br>
      > >>>>
      <a class="moz-txt-link-rfc2396E" href="https://tools.ietf.org/html/rfc7232#section-4.1"><https://tools.ietf.org/html/rfc7232#section-4.1></a><br>
      > >><br>
      > >>>> ...<br>
      > >>>>><br>
      > >>>>> According to RFC 2616, it comes from
      client's browser cache, make<br>
      > >>>>> revalidation, discover content no
      changed and return 304 code.<br>
      > >>>>><br>
      > >>>>> So, it must means (exactly) CLIENT_HIT,
      right?<br>
      > >>>>><br>
      > >><br>
      > >>>> No. Squid does not receive transactions that
      would match the meaning of<br>
      > >>>> the tags CLIENT_HIT.<br>
      > >>> Ok.<br>
      > >><br>
      > >><br>
      > >><br>
      > >>>>> My question is:<br>
      > >>>>><br>
      > >>>>> *Why Squid register this as TCP_MISS/304
      in access.log, when logically<br>
      > >>>>> expect TCP_CLIENT_HIT/304?*<br>
      > >><br>
      > >>>> This is a MISS on the Squid cache. A 304
      from the server delivered to<br>
      > >>>> the client.<br>
      > >>> Ok, 304 delivered. But content - not, right? So,
      this is HIT - even not<br>
      > >>> Squid's hit, yes?<br>
      > >> In agreement with this
      (<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc7232#page-18">https://tools.ietf.org/html/rfc7232#page-18</a>):<br>
      > >><br>
      ><br>
      > > Unknown without seeing the client request headers.</span><br>
    A bit disagree.<br>
    <br>
    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.<br>
    When we seen ??????/304 with only headers - most probably content
    behind proxy already and this is CLIENT_IMS_HIT observed.<br>
    <br>
    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.<br>
    <br>
    Right?<br>
    <span style="white-space: pre;">><br>
      > > There might be no content in Squid cache at the start,
      and due to 304<br>
      > > not providing a payload none at the end either.<br>
      > In given example I know exactly content already in client
      cache and<br>
      > Squid's too. This record occurs due to web-page, contains
      auto-refresh<br>
      > code/pragma. And does periodically refresh.<br>
      ><br>
      > Well, is it possible to make this known? We're on proxy
      between client<br>
      > and web-server. So, it can be easy - сode 304 is immediately
      after the<br>
      > reload/refresh query by the same client.<br>
      ><br>
      > It is not possible to pre-remember that it sent the client in
      the header<br>
      > - or a request for an update - and create the correct tag?
      And not on<br>
      > the principle of "We broke to determine that it is - so that
      we log this<br>
      > as TCP_MISS."<br>
      ><br>
      > It seems to me, such behavior would be more appropriate, and
      more than<br>
      > would be consistent with RFC.<br>
      ><br>
      > Right?<br>
      ><br>
      ><br>
      ><br>
      > >><br>
      > >>>> It might be a CLIENT_IMS_UNMODIFIED or
      CLIENT_INM_UNMODIFIED if Squid<br>
      > >>>> had codes for those cases.<br>
      > >>> Ok, Squid has?<br>
      ><br>
      > > Squid has TCP_MISS tag, which is used for unknown
      situations where a<br>
      > > server was involved.<br>
      ><br>
      > > Amos<br>
      > > _______________________________________________<br>
      > > squid-users mailing list<br>
      > > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      ></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJX/8nBAAoJENNXIZxhPexG6O4H/RSPqYtUJc/c13sENtup86gH
<br>
    5tg3n1QeU5xLOF0k+osexcvAwf/McuFux4aVN92yJw6F2A3PvQSksdDSo0PVNNZZ
<br>
    tHQAotiqdxf2NvwU+ZTP91UxYpl8UhNBtWYanWLsrH4taTPznKYmvCQ/TNwTWFqB
<br>
    R9Wa8KTN1OqX7AK3uRYiCdhzjO/+wwg9p+1RA+YaVNJGBuA/Gp2ANXkeZsgZK4Nn
<br>
    pDfmGP/Jg2TmaRgnPe8U4bZnkYzLcoOaIy/ytM8ePxJiVlHyEBMohjrfZUN6/Nez
<br>
    9GwwA3mRl5MH8DsDz8Ro/7D5DHirnVzfWdGBMFzk12kL/SF7uR/XjvRyohAqtps=
<br>
    =mIPv
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>