Re: [squid-users] TCP_MISS/304 question

[Alex Rousskov]

Hello,

What may help us move forward is a "reverse mapping" table like this
one:

Row (client-Squid) headings:
* response body sent by Squid to client
* 304 response sent by Squid to client
* 412 response sent by Squid to client
...


Column (Squid-server) headings:
* no contact with the server
* response body sent by server to Squid
* 304 response sent by server to Squid
* 412 response sent by server to Squid
...

Each table cell represents a single transaction matching the
intersection of row and column conditions. A cell will contain the
corresponding logged Squid-to-client HTTP status code (where known) and
Squid tag. Some cells may have several lines if several code/tag
combinations are possible.


With some luck, we could then agree which cells should be designated as
"hits", effectively defining what a "hit" is. We may define several
kinds of hits, of course.

I cannot volunteer to fill this table right now, but I think it could be
useful.


HTH,

Alex.
P.S. This 2D table cannot cover all cases, but we can focus on those
successful transactions that affect hit definition(s) under ordinary
conditions (no aborts, no 503s, etc.).

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TCP_MISS/304 question

[Amos Jeffries]

On 15/10/2016 1:36 a.m., Yuri Voinov wrote:
> 
> 
> 
> 14.10.2016 18:30, Amos Jeffries пишет:
>> On 15/10/2016 12:34 a.m., Yuri Voinov wrote:
>>>
>>> A bit more details.
>>>
>>> This is 4 transactions in chronological order. Two from wget -S and two
>>> from same PC via browser for the same URL:
>>>
>>> *root @ khorne /tmp # wget -S
>>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
>>> --2016-10-14 17:18:05--
>>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>>> Connecting to 127.0.0.1:3128... connected.
>>> Proxy request sent, awaiting response...
>>>   HTTP/1.1 301 Moved Permanently
>>>   Server: nginx
>>>   Date: Fri, 14 Oct 2016 11:18:07 GMT
>>>   Content-Type: text/html
>>>   Content-Length: 178
>>>   Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>>>   X-Cache: MISS from khorne
>>>   X-Cache-Lookup: MISS from khorne:3128
>>>   Connection: keep-alive
>>> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> [following]
>>> --2016-10-14 17:18:07--
>>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> 
>> Notice how the Location header made wget fetch send a second fetch to
>> *actually* load an HTTPS object.
> 
>> This means your use of HTTP is irrelevant. HTTP just results in an 301
>> response. That is the end of the HTTP...
> 
> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> 
> This is no matter.
> 
> 
> 
>>> Connecting to 127.0.0.1:3128... connected.
>>> Proxy request sent, awaiting response...
>>>   HTTP/1.1 200 OK
>>>   Server: nginx
>>>   Date: Fri, 14 Oct 2016 10:45:57 GMT
>>>   Content-Type: application/javascript; charset=windows-1251
>>>   Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>>>   ETag: W/"cdf370-758-52351a306ac80"
>>>   Cache-Control: max-age=3600
>>>   Expires: Fri, 14 Oct 2016 11:45:57 GMT
>>>   Access-Control-Allow-Origin: *
>>>   Age: 1930
>>>   X-Cache: HIT from khorne
>>>   X-Cache-Lookup: HIT from khorne:3128
>>>   Transfer-Encoding: chunked
>>>   Connection: keep-alive
>>> Length: unspecified [application/javascript]
>>> Saving to: 'gazeta.media.query.js'
>>>
>>> gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
>>> 0s
>>>
>>> 2016-10-14 17:18:07 (138 MB/s) - 'gazeta.media.query.js' saved [1880]
>>>
>>> /HTTP object in cache and HIT./
> 
>> No. *HTTPS* object in cache and HIT.
> Oh, mistype. Let it be HTTPS and HIT.
> 
> 
> 
>>> *
>>> **root @ khorne /tmp # wget -S
>>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
>>> --2016-10-14 17:18:30--
>>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>>> Connecting to 127.0.0.1:3128... connected.
>>> Proxy request sent, awaiting response...
>>>   HTTP/1.1 200 OK
>>>   Server: nginx
>>>   Date: Fri, 14 Oct 2016 10:45:57 GMT
>>>   Content-Type: application/javascript; charset=windows-1251
>>>   Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>>>   ETag: W/"cdf370-758-52351a306ac80"
>>>   Cache-Control: max-age=3600
>>>   Expires: Fri, 14 Oct 2016 11:45:57 GMT
>>>   Access-Control-Allow-Origin: *
>>>   Age: 1953
>>>   X-Cache: HIT from khorne
>>>   X-Cache-Lookup: HIT from khorne:3128
>>>   Transfer-Encoding: chunked
>>>   Connection: keep-alive
>>> Length: unspecified [application/javascript]
>>> Saving to: 'gazeta.media.query.js.1'
>>>
>>> gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
>>> 0s
>>>
>>> 2016-10-14 17:18:30 (120 MB/s) - 'gazeta.media.query.js.1' saved [1880]
>>>
>>> /HTTPS object in cache and HIT too./
> 
>> No. Same HTTPS object from test #1 is still in cache and still being HIT.
> 
>>>
>>> This is ok.
> 
>> Uh, not if you are going to interpret the first test as being an HTTP
>> object in cache.
> 
>> What this tells is that fetching an HTTPS object twice in a row will
>> produce a HIT.
> Yes. Let it be.
> 
> 
>>>
>>> *Ctrl+F5 (force reload) from browser:*
>>>
>>> 1476443947.419 92 192.168.100.103 TCP_MISS/200 2323 GET
>>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
>>> HIER_DIRECT/81.19.72.0 application/javascript
>>>
>>> MISS - it is ok too, client browser sends no-cache.
> 
>> Did you check the client request to verify that "no-cache" statement?
> Yes.
> 
> 
>>>
>>> At this point we sure object in cache, right? Both in proxy cache and in
>>> client cache (client is the same in attempt 3 and 4). Now - refresh from
>>> browser on the same page (same session), which is equivalent of page
>>> auto-refresh.
> 
>> Yes, that is a reasonable state to assume at this point. Though possibly
>> wrong, since it is an assumption.
> 
>>>
>>> *F5 (refresh) from the same browser:*
>>>
> 
>> NP: be aware that two fetches in a row is different form force-refresh,
>> which is different from non-forced refresh.
> 
>> One of the two refresh involved no-cache header, the other involves
>> max-age=0 header.
>> The double-fetch does not send either no-cache nor max-age=0.
> 
>> Also be aware that the MSIE browser name for the button "Refresh" which
>> got copied by the others is browser GUI 

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
Well. Let's made clean, easy to reproduce example.

Let's take one PC behind proxy. Let's clean up any browser's caches.
Let's reboot it for experiment clarity.

Let's take two URLs. One for HTTP and the same for HTTPS. Simple static
image 200 Kb in size.

http://www.opennet.ru/img/carbonsoft1.gif
https://www.opennet.ru/img/carbonsoft1.gif

Let's run Chrome and Firefox on selected PC.

Let's load both object's in browser's cache. Let's verify both in proxy
cache:

1476449165.101537 192.168.100.103 TCP_HIT/200 210951 GET
http://www.opennet.ru/img/carbonsoft1.gif - HIER_NONE/- image/gif

HTTP and HIT. Exactly.

All the same, but via HTTPS:

1476449299.999470 192.168.100.103 TCP_MISS/200 210857 GET
https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238
image/gif

First load. MISS. It's ok.

Second load. Same PC, Firefox:

1476449352.792105 192.168.100.103 TCP_HIT/200 210864 GET
https://www.opennet.ru/img/carbonsoft1.gif - HIER_NONE/- image/gif

HTTPS and HIT. It's ok. As expected.

Same Firefox, F5, refresh:

1476449412.235102 192.168.100.103 TCP_MISS/304 294 GET
https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 -

Same Chrome, F5, refresh (note: object on proxy cache, and in both
browsers caches):

1476449477.621 87 192.168.100.103 TCP_MISS/304 294 GET
https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 -

Let's see on headers:


root @ khorne /tmp # wget -S http://www.opennet.ru/img/carbonsoft1.gif
- --2016-10-14 18:51:56--  http://www.opennet.ru/img/carbonsoft1.gif
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx/1.0.9
  Date: Tue, 11 Oct 2016 17:28:11 GMT
  Content-Type: image/gif
  Content-Length: 210501
  Last-Modified: Mon, 05 Sep 2016 12:35:00 GMT
  Expires: Thu, 10 Nov 2016 17:28:11 GMT
  Cache-Control: max-age=2592000
  Accept-Ranges: bytes
  Age: 242631
  Warning: 113 khorne (squid) This cache hit is still fresh and more
than 1 day old
  X-Cache: HIT from khorne
  X-Cache-Lookup: HIT from khorne:3128
  Connection: keep-alive
Length: 210501 (206K) [image/gif]
Saving to: 'carbonsoft1.gif'

carbonsoft1.gif 100%[==>] 205.57K  --.-KB/sin 0.001s

2016-10-14 18:51:56 (298 MB/s) - 'carbonsoft1.gif' saved [210501/210501]

root @ khorne /tmp # wget -S https://www.opennet.ru/img/carbonsoft1.gif
- --2016-10-14 18:52:20--  https://www.opennet.ru/img/carbonsoft1.gif
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx/1.0.9
  Date: Fri, 14 Oct 2016 12:48:23 GMT
  Content-Type: image/gif
  Content-Length: 210501
  Last-Modified: Mon, 05 Sep 2016 12:35:00 GMT
  Expires: Sun, 13 Nov 2016 12:48:23 GMT
  Cache-Control: max-age=2592000
  Accept-Ranges: bytes
  Age: 241
  X-Cache: HIT from khorne
  X-Cache-Lookup: HIT from khorne:3128
  Connection: keep-alive
Length: 210501 (206K) [image/gif]
Saving to: 'carbonsoft1.gif.1'

carbonsoft1.gif.1   100%[==>] 205.57K   398KB/sin
0.5s   

2016-10-14 18:52:21 (398 KB/s) - 'carbonsoft1.gif.1' saved [210501/210501]

Yes, both HTTP and HTTPS in proxy cache, right? Both is HTTP/1.1, right?
All headers the same, no cache preventing.

Let's refresh from Chrome HTTP object:

1476449587.276111 192.168.100.103 TCP_REFRESH_UNMODIFIED/304 301 GET
http://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 -

Request size = 301

TCP_REFRESH_UNMODIFIED. As expected, ok.

Let's refresh HTTPS from same chrome:

1476449697.991129 192.168.100.103 TCP_MISS/304 294 GET
https://www.opennet.ru/img/carbonsoft1.gif - HIER_DIRECT/81.95.33.238 -

Request size = 294

TCP_MISS/304.

You can easy to reproduce this by youself. Squid 3.5.22.

The question is the same. Latest example must be TCP_REFRESH_UNMODIFIED.
I see no reason why it should be different tnan HTTP object versions.
Squid's begaviour must be the same, as described in RFC. Right? Because
there is absolutely no any reason for this example, why it must be
different.

Agreed?

All the rest is sophistry and does not explain anything.

14.10.2016 18:36, Yuri Voinov пишет:
>
>
>
> 14.10.2016 18:30, Amos Jeffries пишет:
> > On 15/10/2016 12:34 a.m., Yuri Voinov wrote:
> >>
> >> A bit more details.
> >>
> >> This is 4 transactions in chronological order. Two from wget -S and two
> >> from same PC via browser for the same URL:
> >>
> >> *root @ khorne /tmp # wget -S
> >> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
> >> --2016-10-14 17:18:05--
> >> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> >> Connecting to 127.0.0.1:3128... connected.
> >> Proxy request sent, awaiting response...
> >>   HTTP/1.1 301 Moved Permanently
> >>   Server: nginx
> >>   Date: Fri, 14 Oct 2016 11:18:07 GMT
> >>   Content-Type: text/html
> >>   Content-Length: 178
> >>   Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> >>   

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


14.10.2016 18:30, Amos Jeffries пишет:
> On 15/10/2016 12:34 a.m., Yuri Voinov wrote:
>>
>> A bit more details.
>>
>> This is 4 transactions in chronological order. Two from wget -S and two
>> from same PC via browser for the same URL:
>>
>> *root @ khorne /tmp # wget -S
>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
>> --2016-10-14 17:18:05--
>> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>> Connecting to 127.0.0.1:3128... connected.
>> Proxy request sent, awaiting response...
>>   HTTP/1.1 301 Moved Permanently
>>   Server: nginx
>>   Date: Fri, 14 Oct 2016 11:18:07 GMT
>>   Content-Type: text/html
>>   Content-Length: 178
>>   Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>>   X-Cache: MISS from khorne
>>   X-Cache-Lookup: MISS from khorne:3128
>>   Connection: keep-alive
>> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
[following]
>> --2016-10-14 17:18:07--
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>
> Notice how the Location header made wget fetch send a second fetch to
> *actually* load an HTTPS object.
>
> This means your use of HTTP is irrelevant. HTTP just results in an 301
> response. That is the end of the HTTP...

Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js

This is no matter.
>
>
>
>> Connecting to 127.0.0.1:3128... connected.
>> Proxy request sent, awaiting response...
>>   HTTP/1.1 200 OK
>>   Server: nginx
>>   Date: Fri, 14 Oct 2016 10:45:57 GMT
>>   Content-Type: application/javascript; charset=windows-1251
>>   Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>>   ETag: W/"cdf370-758-52351a306ac80"
>>   Cache-Control: max-age=3600
>>   Expires: Fri, 14 Oct 2016 11:45:57 GMT
>>   Access-Control-Allow-Origin: *
>>   Age: 1930
>>   X-Cache: HIT from khorne
>>   X-Cache-Lookup: HIT from khorne:3128
>>   Transfer-Encoding: chunked
>>   Connection: keep-alive
>> Length: unspecified [application/javascript]
>> Saving to: 'gazeta.media.query.js'
>>
>> gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
>> 0s
>>
>> 2016-10-14 17:18:07 (138 MB/s) - 'gazeta.media.query.js' saved [1880]
>>
>> /HTTP object in cache and HIT./
>
> No. *HTTPS* object in cache and HIT.
Oh, mistype. Let it be HTTPS and HIT.
>
>
>
>> *
>> **root @ khorne /tmp # wget -S
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
>> --2016-10-14 17:18:30--
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>> Connecting to 127.0.0.1:3128... connected.
>> Proxy request sent, awaiting response...
>>   HTTP/1.1 200 OK
>>   Server: nginx
>>   Date: Fri, 14 Oct 2016 10:45:57 GMT
>>   Content-Type: application/javascript; charset=windows-1251
>>   Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>>   ETag: W/"cdf370-758-52351a306ac80"
>>   Cache-Control: max-age=3600
>>   Expires: Fri, 14 Oct 2016 11:45:57 GMT
>>   Access-Control-Allow-Origin: *
>>   Age: 1953
>>   X-Cache: HIT from khorne
>>   X-Cache-Lookup: HIT from khorne:3128
>>   Transfer-Encoding: chunked
>>   Connection: keep-alive
>> Length: unspecified [application/javascript]
>> Saving to: 'gazeta.media.query.js.1'
>>
>> gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
>> 0s
>>
>> 2016-10-14 17:18:30 (120 MB/s) - 'gazeta.media.query.js.1' saved [1880]
>>
>> /HTTPS object in cache and HIT too./
>
> No. Same HTTPS object from test #1 is still in cache and still being HIT.
>
>>
>> This is ok.
>
> Uh, not if you are going to interpret the first test as being an HTTP
> object in cache.
>
> What this tells is that fetching an HTTPS object twice in a row will
> produce a HIT.
Yes. Let it be.
>
>
>>
>> *Ctrl+F5 (force reload) from browser:*
>>
>> 1476443947.419 92 192.168.100.103 TCP_MISS/200 2323 GET
>> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
>> HIER_DIRECT/81.19.72.0 application/javascript
>>
>> MISS - it is ok too, client browser sends no-cache.
>
> Did you check the client request to verify that "no-cache" statement?
Yes.
>
>
>>
>> At this point we sure object in cache, right? Both in proxy cache and in
>> client cache (client is the same in attempt 3 and 4). Now - refresh from
>> browser on the same page (same session), which is equivalent of page
>> auto-refresh.
>
> Yes, that is a reasonable state to assume at this point. Though possibly
> wrong, since it is an assumption.
>
>>
>> *F5 (refresh) from the same browser:*
>>
>
> NP: be aware that two fetches in a row is different form force-refresh,
> which is different from non-forced refresh.
>
> One of the two refresh involved no-cache header, the other involves
> max-age=0 header.
> The double-fetch does not send either no-cache nor max-age=0.
>
> Also be aware that the MSIE browser name for the button "Refresh" which
> got copied by the others is browser GUI terminology, not HTTP terminology.
> HTTP terminology uses "force-refresh" or "reload" for the two request
> header cases caused by F5 and Ctrl+F5.
Sure. In case 

Re: [squid-users] TCP_MISS/304 question

[Amos Jeffries]

On 15/10/2016 12:34 a.m., Yuri Voinov wrote:
> 
> A bit more details.
> 
> This is 4 transactions in chronological order. Two from wget -S and two
> from same PC via browser for the same URL:
> 
> *root @ khorne /tmp # wget -S
> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
> --2016-10-14 17:18:05-- 
> http://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> Connecting to 127.0.0.1:3128... connected.
> Proxy request sent, awaiting response...
>   HTTP/1.1 301 Moved Permanently
>   Server: nginx
>   Date: Fri, 14 Oct 2016 11:18:07 GMT
>   Content-Type: text/html
>   Content-Length: 178
>   Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
>   X-Cache: MISS from khorne
>   X-Cache-Lookup: MISS from khorne:3128
>   Connection: keep-alive
> Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js [following]
> --2016-10-14 17:18:07-- 
> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js

Notice how the Location header made wget fetch send a second fetch to
*actually* load an HTTPS object.

This means your use of HTTP is irrelevant. HTTP just results in an 301
response. That is the end of the HTTP...


> Connecting to 127.0.0.1:3128... connected.
> Proxy request sent, awaiting response...
>   HTTP/1.1 200 OK
>   Server: nginx
>   Date: Fri, 14 Oct 2016 10:45:57 GMT
>   Content-Type: application/javascript; charset=windows-1251
>   Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>   ETag: W/"cdf370-758-52351a306ac80"
>   Cache-Control: max-age=3600
>   Expires: Fri, 14 Oct 2016 11:45:57 GMT
>   Access-Control-Allow-Origin: *
>   Age: 1930
>   X-Cache: HIT from khorne
>   X-Cache-Lookup: HIT from khorne:3128
>   Transfer-Encoding: chunked
>   Connection: keep-alive
> Length: unspecified [application/javascript]
> Saving to: 'gazeta.media.query.js'
> 
> gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
> 0s 
> 
> 2016-10-14 17:18:07 (138 MB/s) - 'gazeta.media.query.js' saved [1880]
> 
> /HTTP object in cache and HIT./

No. *HTTPS* object in cache and HIT.


> *
> **root @ khorne /tmp # wget -S
> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
> --2016-10-14 17:18:30-- 
> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
> Connecting to 127.0.0.1:3128... connected.
> Proxy request sent, awaiting response...
>   HTTP/1.1 200 OK
>   Server: nginx
>   Date: Fri, 14 Oct 2016 10:45:57 GMT
>   Content-Type: application/javascript; charset=windows-1251
>   Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
>   ETag: W/"cdf370-758-52351a306ac80"
>   Cache-Control: max-age=3600
>   Expires: Fri, 14 Oct 2016 11:45:57 GMT
>   Access-Control-Allow-Origin: *
>   Age: 1953
>   X-Cache: HIT from khorne
>   X-Cache-Lookup: HIT from khorne:3128
>   Transfer-Encoding: chunked
>   Connection: keep-alive
> Length: unspecified [application/javascript]
> Saving to: 'gazeta.media.query.js.1'
> 
> gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
> 0s 
> 
> 2016-10-14 17:18:30 (120 MB/s) - 'gazeta.media.query.js.1' saved [1880]
> 
> /HTTPS object in cache and HIT too./

No. Same HTTPS object from test #1 is still in cache and still being HIT.

> 
> This is ok.

Uh, not if you are going to interpret the first test as being an HTTP
object in cache.

What this tells is that fetching an HTTPS object twice in a row will
produce a HIT.

> 
> *Ctrl+F5 (force reload) from browser:*
> 
> 1476443947.419 92 192.168.100.103 TCP_MISS/200 2323 GET
> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
> HIER_DIRECT/81.19.72.0 application/javascript
> 
> MISS - it is ok too, client browser sends no-cache.

Did you check the client request to verify that "no-cache" statement?

> 
> At this point we sure object in cache, right? Both in proxy cache and in
> client cache (client is the same in attempt 3 and 4). Now - refresh from
> browser on the same page (same session), which is equivalent of page
> auto-refresh.

Yes, that is a reasonable state to assume at this point. Though possibly
wrong, since it is an assumption.

> 
> *F5 (refresh) from the same browser:*
> 

NP: be aware that two fetches in a row is different form force-refresh,
which is different from non-forced refresh.

One of the two refresh involved no-cache header, the other involves
max-age=0 header.
The double-fetch does not send either no-cache nor max-age=0.

Also be aware that the MSIE browser name for the button "Refresh" which
got copied by the others is browser GUI terminology, not HTTP terminology.
HTTP terminology uses "force-refresh" or "reload" for the two request
header cases caused by F5 and Ctrl+F5.


> 1476443997.252 96 192.168.100.103 TCP_MISS/304 353 GET
> https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
> HIER_DIRECT/81.19.72.0 -
> 
> Here is it. Object in proxy cache, in client cache, revalidation is ok -
> object not changed. It must be TCP_REFRESH_UNMODIFIED, and this tag
> we've got with HTTP object via browser.

No. I think you have confused the GUI button name with the 

Re: [squid-users] TCP_MISS/304 question

[Amos Jeffries]

On 14/10/2016 10:44 a.m., Yuri Voinov wrote:
> 
> 
> 
> 14.10.2016 2:48, Alex Rousskov пишет:
>> On 10/13/2016 01:44 PM, Yuri Voinov wrote:
> 
>>> However, this is nothing more than word games, Alex.
> 
>> ... unless the definition of a hit affects your billing or your
>> interpretation of Squid documentation or the developer interpretation of
>> the code. Definitions matter! You yourself have seen their importance
>> when you showed your excellent byte hit ratio results but folks were
>> looking at the ordinary document hit ratio numbers instead.
> Sure. But difference with TCP_HIT itself and byte hit is obvious.
> 

Even that is not so obvious as it appears at first. Since 3.5.22 it is
possible that the proxy finds an item in its cache that needs to be
revalidated. When asked the server responds with a 304 that contains
info far older than the proxy found (maybe from a more up-to-date server
IP).
In this situation Squid discards the outdated server response and
deliveres its content. That should be marked as TCP_HIT under the
current tagging system.

This case and others involving the (thankfully rare) If-Unmodified-Since
header are why I am trying to work out a better tagging scheme that will
be less confusing and more descriptive for the operations.


> 
>>> The question is -
>>> can we more or less significant differences from known what hit proxy
>>> code level and / or transactions which, obviously, on the proxy level,
>>> we can see in its entirety.
> 
>> Sorry, I do not understand the question.
> I want to say that on the proxy level, seeing the transaction as a
> whole, we are able to differentiate hit or his likeness from all other
> transactions. We see the whole session in its entirety. We see repeated
> queries of the same client to the same resource. Accordingly, we can
> quite clearly be judged by the behavior of the header from the client or
> server that is happening. Correctly?
> 

HTTP/1.0 was simple. HIT and MISS were easily known and matched what you
have learnt to expect.

HTTP/1.1 adds 2x time-based If-*Since headers, 2x ETag based If-*Match
headrs, and one extendable If: header - each of which has a 200 or 304
response. With a client cache, proxy cache and upstream cache each
having one of the content-vs-nothing states.

The result is that the log line describes one of the 3*(2^5) = 96
different transaction cases which could occur.

My math there is assuming the that each header adds only a binary
condition (X, or not X). If they add trinary (X, not-X, ignore) then its
2^2*(3^4) = 972 cases, which seems a bit much to me.


> Specifically, in this particular case. Proxy IMS settings is enabled:
> 
> refresh_all_ims on
> reload_into_ims on
> 

These are converting CC:no-cache or CC:max-age=0 client headers into IMS
(If-Modified-Since) revalidations against the server. All they do is
convert the Squid<->server transaction into a revalidation.

The client should still get a /200 object even though the server side
used revalidation. It is a bug for Squid to respond to those client
requests with /304 unless the client *also* sent If-* headers along with
the CC reload/refresh header.


> On web-page level we have: periodically reload/refresh directive, which
> is forces to check (after initially store in shared cache) freshness of
> content.
> 

These reload/refresh coming from the client are supposed to only happen
when a user identifies breakage in the web page and manually forces it
to happen (refresh button in the browser). Bots can use them, but should
not need to.

So when HTTP is working properly they should almost never happen (client
never sees breakage).

If you find them happening a lot it is a sign of breakage.


> In this situation (and I've checked this web-page elements stored in
> cache) TCP_MISS/304 means TCP_REFRESH_UNMODIFIED.
> 
> So, this is HIT exactly.

No "exactly" about it.

If it was *exactly* a HIT that would mean the cached response was a 304
message. Not some object the 304 was about, but the actual 304 status
line + mime headers.

Which also would be logged as as TCP_HIT/304. Identical to the different
case where a normal cache object being HIT on generated a new 304 to the
client.

> 
> I'm not saying - literally. And in fact. Correctly?

With 96 permutations of cases there may be the odd mistake. But where
Squid has a tag code for one case that case is usually tagged correctly.
So the TCP_MISS/304 is definitely *not* a TCP_REFRESH_UNMODIFIED - but
it also may not be strictly a MISS either.

It is entirely possible that a TCP_MISS/304 is a real TCP_MISS/304. MISS
on the proxy cache and 304 from upstream server.

The REFRESH MODIFIED/UNMODIFIED tags are give to the time-based
If-*-Since headers. The ETag based ones are not tagged the same because
'(un)modified' is not applicable. So this TCP_MISS/304 may be one of the
ETag revalidations on proxy content that we dont have a special code for
yet.

> 
 Unfortunately, there are too many definitions of a 

Re: [squid-users] TCP_MISS/304 question

[Amos Jeffries]

On 14/10/2016 10:57 p.m., Yuri Voinov wrote:
> 
> It seems I found the root of problem.
> 
> When cached object refreshed and goes via HTTP, it gives
> TCP_REFRESH_UNMODIFIED in access.log, which is correct.
> When the _same_ _cached_ _object_ refreshes and goes via HTTPS, it gives
> TCP_MISS/304 in access.log, and this is wrong.
> 
> It seems like bug.
> 

Assuming you did the test right it does seem that way.

The way you have described it makes me think you are probably not
testing it right. Since HTTPS is not exactly like HTTP (the 'S' has
meaning), your test has to treat the HTTPS object as if it had a
completely different URL to the HTTP one.

HTTP objects are not interchangeable with HTTPS objects, even when the
payload bytes are the same. And that also means you must not use
Store-ID to mix them up.

Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
A bit more details.

This is 4 transactions in chronological order. Two from wget -S and two
from same PC via browser for the same URL:

*root @ khorne /tmp # wget -S
http://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
- --2016-10-14 17:18:05-- 
http://www.gazeta.ru/nm2015/js/gazeta.media.query.js
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 301 Moved Permanently
  Server: nginx
  Date: Fri, 14 Oct 2016 11:18:07 GMT
  Content-Type: text/html
  Content-Length: 178
  Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
  X-Cache: MISS from khorne
  X-Cache-Lookup: MISS from khorne:3128
  Connection: keep-alive
Location: https://www.gazeta.ru/nm2015/js/gazeta.media.query.js [following]
- --2016-10-14 17:18:07-- 
https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx
  Date: Fri, 14 Oct 2016 10:45:57 GMT
  Content-Type: application/javascript; charset=windows-1251
  Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
  ETag: W/"cdf370-758-52351a306ac80"
  Cache-Control: max-age=3600
  Expires: Fri, 14 Oct 2016 11:45:57 GMT
  Access-Control-Allow-Origin: *
  Age: 1930
  X-Cache: HIT from khorne
  X-Cache-Lookup: HIT from khorne:3128
  Transfer-Encoding: chunked
  Connection: keep-alive
Length: unspecified [application/javascript]
Saving to: 'gazeta.media.query.js'

gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
0s 

2016-10-14 17:18:07 (138 MB/s) - 'gazeta.media.query.js' saved [1880]

/HTTP object in cache and HIT./
*
**root @ khorne /tmp # wget -S
https://www.gazeta.ru/nm2015/js/gazeta.media.query.js*
- --2016-10-14 17:18:30-- 
https://www.gazeta.ru/nm2015/js/gazeta.media.query.js
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx
  Date: Fri, 14 Oct 2016 10:45:57 GMT
  Content-Type: application/javascript; charset=windows-1251
  Last-Modified: Fri, 30 Oct 2015 12:33:38 GMT
  ETag: W/"cdf370-758-52351a306ac80"
  Cache-Control: max-age=3600
  Expires: Fri, 14 Oct 2016 11:45:57 GMT
  Access-Control-Allow-Origin: *
  Age: 1953
  X-Cache: HIT from khorne
  X-Cache-Lookup: HIT from khorne:3128
  Transfer-Encoding: chunked
  Connection: keep-alive
Length: unspecified [application/javascript]
Saving to: 'gazeta.media.query.js.1'

gazeta.media.query. [ <=>   ]   1.84K  --.-KB/sin
0s 

2016-10-14 17:18:30 (120 MB/s) - 'gazeta.media.query.js.1' saved [1880]

/HTTPS object in cache and HIT too./

This is ok.

*Ctrl+F5 (force reload) from browser:*

1476443947.419 92 192.168.100.103 TCP_MISS/200 2323 GET
https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
HIER_DIRECT/81.19.72.0 application/javascript

MISS - it is ok too, client browser sends no-cache.

At this point we sure object in cache, right? Both in proxy cache and in
client cache (client is the same in attempt 3 and 4). Now - refresh from
browser on the same page (same session), which is equivalent of page
auto-refresh.

*F5 (refresh) from the same browser:*

1476443997.252 96 192.168.100.103 TCP_MISS/304 353 GET
https://www.gazeta.ru/nm2015/js/gazeta.media.query.js -
HIER_DIRECT/81.19.72.0 -

Here is it. Object in proxy cache, in client cache, revalidation is ok -
object not changed. It must be TCP_REFRESH_UNMODIFIED, and this tag
we've got with HTTP object via browser.

/But shit! HTTPS goes TCP_MISS/304! We're expected to get
TCP_REFRESH_UNMODIFIED/304! Because this is refresh operation, we're
sure object in both caches - proxy and client, revalidation is ok, but
this marks as MISS./

Why HTTP refresh goes with TCP_REFRESH_UNMODIFIED, and the same object
via HTTPS goes with TCP_MISS? As shown above, object has no headers
preventing caching.

Is it bug or feature? Because of, when site goes under HTTPS, it will
has lower hit with the same content. It seems wrong.

Note: This is news site. There is no private headers or any other
cache-preventing headers.

14.10.2016 15:57, Yuri Voinov пишет:
>
> It seems I found the root of problem.
>
> When cached object refreshed and goes via HTTP, it gives
TCP_REFRESH_UNMODIFIED in access.log, which is correct.
> When the _same_ _cached_ _object_ refreshes and goes via HTTPS, it
gives TCP_MISS/304 in access.log, and this is wrong.
>
> It seems like bug.
>
> 14.10.2016 3:44, Yuri Voinov пишет:
>
>
>
>
>
>
>   > 14.10.2016 2:48, Alex Rousskov пишет:
>
>   > > On 10/13/2016 01:44 PM, Yuri Voinov wrote:
>
>
>
>   > >> However, this is nothing more than word games, Alex.
>
>
>
>   > > ... unless the definition of a hit affects your billing
>   or your
>
>   > > interpretation of Squid documentation or the developer
>   interpretation of
>
>   > > the code. Definitions matter! You yourself have seen
>   their importance
>
>   > > when you 

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
It seems I found the root of problem.

When cached object refreshed and goes via HTTP, it gives
TCP_REFRESH_UNMODIFIED in access.log, which is correct.
When the _same_ _cached_ _object_ refreshes and goes via HTTPS, it gives
TCP_MISS/304 in access.log, and this is wrong.

It seems like bug.

14.10.2016 3:44, Yuri Voinov пишет:
>
>
>
> 14.10.2016 2:48, Alex Rousskov пишет:
> > On 10/13/2016 01:44 PM, Yuri Voinov wrote:
>
> >> However, this is nothing more than word games, Alex.
>
> > ... unless the definition of a hit affects your billing or your
> > interpretation of Squid documentation or the developer interpretation of
> > the code. Definitions matter! You yourself have seen their importance
> > when you showed your excellent byte hit ratio results but folks were
> > looking at the ordinary document hit ratio numbers instead.
> Sure. But difference with TCP_HIT itself and byte hit is obvious.
>
>
>
> >> The question is -
> >> can we more or less significant differences from known what hit proxy
> >> code level and / or transactions which, obviously, on the proxy level,
> >> we can see in its entirety.
>
> > Sorry, I do not understand the question.
> I want to say that on the proxy level, seeing the transaction as a
> whole, we are able to differentiate hit or his likeness from all other
> transactions. We see the whole session in its entirety. We see repeated
> queries of the same client to the same resource. Accordingly, we can
> quite clearly be judged by the behavior of the header from the client or
> server that is happening. Correctly?
>
> Specifically, in this particular case. Proxy IMS settings is enabled:
>
> refresh_all_ims on
> reload_into_ims on
>
> On web-page level we have: periodically reload/refresh directive, which
> is forces to check (after initially store in shared cache) freshness of
> content.
>
> In this situation (and I've checked this web-page elements stored in
> cache) TCP_MISS/304 means TCP_REFRESH_UNMODIFIED.
>
> So, this is HIT exactly.
>
> I'm not saying - literally. And in fact. Correctly?
>
>
>
> >>> Unfortunately, there are too many definitions of a "hit".
>
> >> There is no many definitions of hit. We are talking about the caching
> >> proxy, which is basically no different from all the other caches, and
> >> subject to the same rules.
>
> > You are oversimplifying a complex subject matter. If Squid delivers a
> > single response comprising 1000 bytes from the cache and 10 bytes from
> > the origin server, is that a hit or a miss? If Squid delivers the entire
> > response from the cache but spends 10 minutes talking to the origin
> > server about that object first, is that a hit or a miss? Different
> > people will give you different answers to those questions.
> 10 minutes a bit above TCP timeout and will be aborted, I think. So,
> Squid's write TCP_MISS_ABORTED in access.log. :)
>
>
> > We have [poorly defined] byte hits, document hits, revalidation hits,
> > stale hits, partial hits, etc., etc.
> What yes - yes. The documentation is the problem.
>
>
>
> >> If the first access does not find an object in the cache, it requests
> >> from the network,
>
> > yes
>
> >> saves in the cache,
>
> > or does not
> Yes. May be or may be not. But in this case we are:
> 1) Know about transaction history and we know the object(s) in cache.
> 2) Proxy can easy check it, right? Just swap in object from disk in
> memory. If this success, object in cache, so we can qualify it as HIT.
> Otherwise, exactly MISS.
>
>
> >> and re-treatment or gets a hit,
>
> > or does not
>
> >> "the object is not changed." Dot.
>
> > or the Squid-cached object did not change but the client-cached object
> > did. Or vice versa.
> Client-cached object gives from Squid. They (ideally) must not be the
> different. Client cache and squid's cache operates like chain, one is
> source for another.
>
>
>
> >> If the time in the cache
> >> object lifetime expires, or a lifetime on the server timed out - the
> >> object is requested again and a miss is recorded.
>
> > * Yes, if you define a miss as "contact with the origin server".
> I want to add: "contact with the origin server for get content". Not for
> revalidation purposes. If revalidation returns "Object not changed" -
> this is positive and must be qualified as HIT IMO.
>
> > * No, if contact with the origin server is OK for a hit as long as the
> > server does not send the response _body_ back to Squid.
>  when revalidation true - i.e. object in shared cache not stale,
> this is HIT. We're not interested in client browser's cache state. Only
> shared cache matters.
>
>
>
> >> if
> >> the proxy responds to the client "has not changed", it means, in fact,
> >> that the client has a copy of the object
>
> > Yes.
>
> >> and a copy of the proxy object,
>
> > The copy in the proxy cache may be different from the copy in the client
> > cache or may not exist at all.
> Yes. If object not exists in proxy - this 

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


14.10.2016 2:48, Alex Rousskov пишет:
> On 10/13/2016 01:44 PM, Yuri Voinov wrote:
>
>> However, this is nothing more than word games, Alex.
>
> ... unless the definition of a hit affects your billing or your
> interpretation of Squid documentation or the developer interpretation of
> the code. Definitions matter! You yourself have seen their importance
> when you showed your excellent byte hit ratio results but folks were
> looking at the ordinary document hit ratio numbers instead.
Sure. But difference with TCP_HIT itself and byte hit is obvious.
>
>
>
>> The question is -
>> can we more or less significant differences from known what hit proxy
>> code level and / or transactions which, obviously, on the proxy level,
>> we can see in its entirety.
>
> Sorry, I do not understand the question.
I want to say that on the proxy level, seeing the transaction as a
whole, we are able to differentiate hit or his likeness from all other
transactions. We see the whole session in its entirety. We see repeated
queries of the same client to the same resource. Accordingly, we can
quite clearly be judged by the behavior of the header from the client or
server that is happening. Correctly?

Specifically, in this particular case. Proxy IMS settings is enabled:

refresh_all_ims on
reload_into_ims on

On web-page level we have: periodically reload/refresh directive, which
is forces to check (after initially store in shared cache) freshness of
content.

In this situation (and I've checked this web-page elements stored in
cache) TCP_MISS/304 means TCP_REFRESH_UNMODIFIED.

So, this is HIT exactly.

I'm not saying - literally. And in fact. Correctly?

>
>
>>> Unfortunately, there are too many definitions of a "hit".
>
>> There is no many definitions of hit. We are talking about the caching
>> proxy, which is basically no different from all the other caches, and
>> subject to the same rules.
>
> You are oversimplifying a complex subject matter. If Squid delivers a
> single response comprising 1000 bytes from the cache and 10 bytes from
> the origin server, is that a hit or a miss? If Squid delivers the entire
> response from the cache but spends 10 minutes talking to the origin
> server about that object first, is that a hit or a miss? Different
> people will give you different answers to those questions.
10 minutes a bit above TCP timeout and will be aborted, I think. So,
Squid's write TCP_MISS_ABORTED in access.log. :)
>
>
> We have [poorly defined] byte hits, document hits, revalidation hits,
> stale hits, partial hits, etc., etc.
What yes - yes. The documentation is the problem.
>
>
>
>> If the first access does not find an object in the cache, it requests
>> from the network,
>
> yes
>
>> saves in the cache,
>
> or does not
Yes. May be or may be not. But in this case we are:
1) Know about transaction history and we know the object(s) in cache.
2) Proxy can easy check it, right? Just swap in object from disk in
memory. If this success, object in cache, so we can qualify it as HIT.
Otherwise, exactly MISS.
>
>
>> and re-treatment or gets a hit,
>
> or does not
>
>> "the object is not changed." Dot.
>
> or the Squid-cached object did not change but the client-cached object
> did. Or vice versa.
Client-cached object gives from Squid. They (ideally) must not be the
different. Client cache and squid's cache operates like chain, one is
source for another.
>
>
>
>> If the time in the cache
>> object lifetime expires, or a lifetime on the server timed out - the
>> object is requested again and a miss is recorded.
>
> * Yes, if you define a miss as "contact with the origin server".
I want to add: "contact with the origin server for get content". Not for
revalidation purposes. If revalidation returns "Object not changed" -
this is positive and must be qualified as HIT IMO.
>
> * No, if contact with the origin server is OK for a hit as long as the
> server does not send the response _body_ back to Squid.
 when revalidation true - i.e. object in shared cache not stale,
this is HIT. We're not interested in client browser's cache state. Only
shared cache matters.
>
>
>
>> if
>> the proxy responds to the client "has not changed", it means, in fact,
>> that the client has a copy of the object
>
> Yes.
>
>> and a copy of the proxy object,
>
> The copy in the proxy cache may be different from the copy in the client
> cache or may not exist at all.
Yes. If object not exists in proxy - this is proxy MISS. If client cache
not contains object - client go to proxy and asks it about object. Found
- excellent, for client this is MISS, for proxy - HIT. If proxy also not
contains object - it will be MISS-MISS and loading object from origin.

>
>
>
>> the proxy and responds to the client, performing REFRESH that the object
>> did not change. What is this, if not hit?
>
> Assuming the proxy asked the origin server whether the object in the
> client (or the proxy, depending on the circumstances) 

Re: [squid-users] TCP_MISS/304 question

[Alex Rousskov]

On 10/13/2016 01:44 PM, Yuri Voinov wrote:

> However, this is nothing more than word games, Alex. 

... unless the definition of a hit affects your billing or your
interpretation of Squid documentation or the developer interpretation of
the code. Definitions matter! You yourself have seen their importance
when you showed your excellent byte hit ratio results but folks were
looking at the ordinary document hit ratio numbers instead.


> The question is -
> can we more or less significant differences from known what hit proxy
> code level and / or transactions which, obviously, on the proxy level,
> we can see in its entirety.

Sorry, I do not understand the question.


>> Unfortunately, there are too many definitions of a "hit".

> There is no many definitions of hit. We are talking about the caching
> proxy, which is basically no different from all the other caches, and
> subject to the same rules.

You are oversimplifying a complex subject matter. If Squid delivers a
single response comprising 1000 bytes from the cache and 10 bytes from
the origin server, is that a hit or a miss? If Squid delivers the entire
response from the cache but spends 10 minutes talking to the origin
server about that object first, is that a hit or a miss? Different
people will give you different answers to those questions.

We have [poorly defined] byte hits, document hits, revalidation hits,
stale hits, partial hits, etc., etc.


> If the first access does not find an object in the cache, it requests
> from the network,

yes

> saves in the cache,

or does not

> and re-treatment or gets a hit,

or does not

> "the object is not changed." Dot.

or the Squid-cached object did not change but the client-cached object
did. Or vice versa.


> If the time in the cache
> object lifetime expires, or a lifetime on the server timed out - the
> object is requested again and a miss is recorded.

* Yes, if you define a miss as "contact with the origin server".
* No, if contact with the origin server is OK for a hit as long as the
server does not send the response _body_ back to Squid.


> if
> the proxy responds to the client "has not changed", it means, in fact,
> that the client has a copy of the object

Yes.

> and a copy of the proxy object,

The copy in the proxy cache may be different from the copy in the client
cache or may not exist at all.


> the proxy and responds to the client, performing REFRESH that the object
> did not change. What is this, if not hit?

Assuming the proxy asked the origin server whether the object in the
client (or the proxy, depending on the circumstances) cache is fresh,
for many, it is

* a [document] miss (because there was a potentially very slow contact
with the origin server) or
* a [byte] hit (because the response body came from the Squid cache and
not from the origin server).

Resisting the existence of different valid hit definitions is futile
IMO. State what _your_ definition is (be as precise as possible; this
may require several iterations) and then you may ask whether a
particular transaction is a hit.

Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


14.10.2016 1:28, Alex Rousskov пишет:
> On 10/13/2016 12:46 PM, Yuri Voinov wrote:
>>
>>
>> 14.10.2016 0:28, Alex Rousskov пишет:
>>> On 10/13/2016 11:52 AM, Yuri Voinov wrote:
 When we seen ??/304 with only headers - most probably content
behind
 proxy already and this is CLIENT_IMS_HIT observed.
>
>>> A 304 code sent by Squid to the client means "Squid told the client that
>>> the client has a fresh copy (or equivalent)". It does not tell us how
>>> Squid came up with that answer, or what Squid has in its cache: We do
>>> not know whether Squid had the corresponding entry cached when the
>>> client request came. If Squid had that entry cached, then Squid may or
>>> may not have tried to validate it. If Squid tried to validate, then
>>> Squid may or may not have gotten an entry from the origin server.
>>> Finally, we do not know whether Squid kept, replaced, or deleted the
>>> cache entry as the result of that validation attempt.
>>
>>> For an extreme example, consider Squid without a cache. Such a
>>> configuration will still have lots of /304 entries in access.log!
>>
>>> A single access.log line (and often even a single Squid result code on
>>> that line!) is telling us what happened when Squid talked to the client
>>> _and_ what happened when Squid talked to the server (if it did talk to
>>> the server). One cannot gain that vital information from a single HTTP
>>> status code alone.
>>
>>
>>> Many folks disagree regarding the best way to structure Squid result
>>> codes. Many also disagree regarding the best definition for "cache hit".
>>> All the different approaches make it very difficult to discuss these
>>> matters and maintain related code. A /304 field alone means the client
>>> got an HTTP 304 response. Whether you call that a "hit" from Squid point
>>> of view depends on your definition of "hit" _and_ (depending on that
>>> definition) on other factors that /304 does not reveal. For example:
>>
>>> * if your definition of a "hit" is "Squid did not talk to the origin
>>> server or peer", then /304 alone does not necessarily mean a hit.
>> But most probably, right?
>
> The probability is determined by the environment. I have already given
> you a simple example where _all_ /304s mean that Squid talked to the
> origin server. In that environment, the probability is 0. There are lots
> of environments. I do not know what is "most probable" in yours.
>
>
>
>>> * if your definition of a "hit" is "Squid did not receive a large
>>> response from the origin server or peer", then /304 alone does not
>>> necessarily mean a hit.
>> But still most probably, yes?
>
> Same answer. I have seen environments where this probability will be
> close to zero for this definition of a "hit".
>
>
>> Alone - agreed, Alex. But we've can see all transaction, right?
>
> Sure, but your original question was about /304 alone and you have
> resisted Amos' attempts to get more transaction information (AFAICT).
Mea culpa. I thought it obvious that, once I show an entry from the log,
I have entire log and, of course, that this is only part of the
transaction, which sees the whole entire proxy.

However, this is nothing more than word games, Alex. The question is -
can we more or less significant differences from known what hit proxy
code level and / or transactions which, obviously, on the proxy level,
we can see in its entirety.
>
>
>
>> So, if we've already done request to the same URL in the past, got
>> TCP_MISS, then get again, _and_ has saved copy in cache, _and_ we're got
>> 304 - this is hit. For shared cache itself.
>
> Depends on your definition of a hit. And even if Squid cached Xv2 during
> the previous transaction, does not mean Squid did not revalidate Xv2
> during the last transaction, did not receive Xv3 from a peer, and the
> client does not already have and is revalidating Xv4. Yes, there are
> certainly lots of cases where what you think is happening is actually
> happening, but there are other cases as well.
>
>
>> But: If something behaves like a hit, it looks like a hit and quacks
>> like a hit - it hit. :)
>
> Unfortunately, there are too many definitions of a "hit".
There is no many definitions of hit. We are talking about the caching
proxy, which is basically no different from all the other caches, and
subject to the same rules.

_If the first access does not find an object in the cache, it requests
from the network, saves in the cache, and re-treatment or gets a hit,
"the object is not changed." Dot. Further. If the time in the cache
object lifetime expires, or a lifetime on the server timed out - the
object is requested again and a miss is recorded._

The fact that we do not know that there is a client with the object? It
is not our business. It is the client's problem. If the client cache get
miss for an object that no longer exists or its lifetime has expired -
he asks his proxy. Proxy, in the future, or fixes hit or miss. Thus, if

Re: [squid-users] TCP_MISS/304 question

[Alex Rousskov]

On 10/13/2016 12:46 PM, Yuri Voinov wrote:
> 
> 
> 14.10.2016 0:28, Alex Rousskov пишет:
>> On 10/13/2016 11:52 AM, Yuri Voinov wrote:
>>> When we seen ??/304 with only headers - most probably content behind
>>> proxy already and this is CLIENT_IMS_HIT observed.

>> A 304 code sent by Squid to the client means "Squid told the client that
>> the client has a fresh copy (or equivalent)". It does not tell us how
>> Squid came up with that answer, or what Squid has in its cache: We do
>> not know whether Squid had the corresponding entry cached when the
>> client request came. If Squid had that entry cached, then Squid may or
>> may not have tried to validate it. If Squid tried to validate, then
>> Squid may or may not have gotten an entry from the origin server.
>> Finally, we do not know whether Squid kept, replaced, or deleted the
>> cache entry as the result of that validation attempt.
> 
>> For an extreme example, consider Squid without a cache. Such a
>> configuration will still have lots of /304 entries in access.log!
> 
>> A single access.log line (and often even a single Squid result code on
>> that line!) is telling us what happened when Squid talked to the client
>> _and_ what happened when Squid talked to the server (if it did talk to
>> the server). One cannot gain that vital information from a single HTTP
>> status code alone.
> 
> 
>> Many folks disagree regarding the best way to structure Squid result
>> codes. Many also disagree regarding the best definition for "cache hit".
>> All the different approaches make it very difficult to discuss these
>> matters and maintain related code. A /304 field alone means the client
>> got an HTTP 304 response. Whether you call that a "hit" from Squid point
>> of view depends on your definition of "hit" _and_ (depending on that
>> definition) on other factors that /304 does not reveal. For example:
> 
>> * if your definition of a "hit" is "Squid did not talk to the origin
>> server or peer", then /304 alone does not necessarily mean a hit.
> But most probably, right?

The probability is determined by the environment. I have already given
you a simple example where _all_ /304s mean that Squid talked to the
origin server. In that environment, the probability is 0. There are lots
of environments. I do not know what is "most probable" in yours.



>> * if your definition of a "hit" is "Squid did not receive a large
>> response from the origin server or peer", then /304 alone does not
>> necessarily mean a hit.
> But still most probably, yes?

Same answer. I have seen environments where this probability will be
close to zero for this definition of a "hit".


> Alone - agreed, Alex. But we've can see all transaction, right?

Sure, but your original question was about /304 alone and you have
resisted Amos' attempts to get more transaction information (AFAICT).


> So, if we've already done request to the same URL in the past, got
> TCP_MISS, then get again, _and_ has saved copy in cache, _and_ we're got
> 304 - this is hit. For shared cache itself.

Depends on your definition of a hit. And even if Squid cached Xv2 during
the previous transaction, does not mean Squid did not revalidate Xv2
during the last transaction, did not receive Xv3 from a peer, and the
client does not already have and is revalidating Xv4. Yes, there are
certainly lots of cases where what you think is happening is actually
happening, but there are other cases as well.


> But: If something behaves like a hit, it looks like a hit and quacks
> like a hit - it hit. :)

Unfortunately, there are too many definitions of a "hit".

Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 

14.10.2016 0:28, Alex Rousskov пишет:
> On 10/13/2016 11:52 AM, Yuri Voinov wrote:
>> 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?
>
> Wrong.
>
> A 304 code sent by Squid to the client means "Squid told the client that
> the client has a fresh copy (or equivalent)". It does not tell us how
> Squid came up with that answer, or what Squid has in its cache: We do
> not know whether Squid had the corresponding entry cached when the
> client request came. If Squid had that entry cached, then Squid may or
> may not have tried to validate it. If Squid tried to validate, then
> Squid may or may not have gotten an entry from the origin server.
> Finally, we do not know whether Squid kept, replaced, or deleted the
> cache entry as the result of that validation attempt.
>
> For an extreme example, consider Squid without a cache. Such a
> configuration will still have lots of /304 entries in access.log!
>
> A single access.log line (and often even a single Squid result code on
> that line!) is telling us what happened when Squid talked to the client
> _and_ what happened when Squid talked to the server (if it did talk to
> the server). One cannot gain that vital information from a single HTTP
> status code alone.
>
>
> Many folks disagree regarding the best way to structure Squid result
> codes. Many also disagree regarding the best definition for "cache hit".
> All the different approaches make it very difficult to discuss these
> matters and maintain related code. A /304 field alone means the client
> got an HTTP 304 response. Whether you call that a "hit" from Squid point
> of view depends on your definition of "hit" _and_ (depending on that
> definition) on other factors that /304 does not reveal. For example:
>
> * if your definition of a "hit" is "Squid did not talk to the origin
> server or peer", then /304 alone does not necessarily mean a hit.
But most probably, right?
>
>
> * if your definition of a "hit" is "Squid did not receive a large
> response from the origin server or peer", then /304 alone does not
> necessarily mean a hit.
But still most probably, yes?

Alone - agreed, Alex. But we've can see all transaction, right?

So, if we've already done request to the same URL in the past, got
TCP_MISS, then get again, _and_ has saved copy in cache, _and_ we're got
304 - this is hit. For shared cache itself.

We're not consider cases of HTTP violations - we're respect RFC.  :)

But: If something behaves like a hit, it looks like a hit and quacks
like a hit - it hit. :)
>
>
>
> HTH,
>
> Alex.
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJX/9aGAAoJENNXIZxhPexGBOMH/iz2NXmTfcVrCMq0Do2sOz2M
ndhc1Pi60HoLYle9zgKfBA4qS5ozHuUyVN96IYcCtu0y/2+IxhnAoliSUTveQTjm
06tXcQtq+6fsEJNmLsF/cMPO3cFGlp8zbjup1P94S8yNyKbsjXGgyWyCIlOtEqT4
uaMRG2dDCx2XzdvLOpW92XSKn6jeF8dYMhLSQy3offbkPoabqQXTyNo+vvZCR4gE
jhtGhLMCFW4/GD1RoDPdI0Gf+4sKdMtOlP5KrS4BCebQ+HQeCKGTnbpbr46wEVWy
PbF1dCnl9REH6Q/sNCXmRwxImFr89Go8VWvzugigGktlRsMM01VFEEIqjzlCQuw=
=47G3
-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

Re: [squid-users] TCP_MISS/304 question

[Alex Rousskov]

On 10/13/2016 11:52 AM, Yuri Voinov wrote:
> 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?

Wrong.

A 304 code sent by Squid to the client means "Squid told the client that
the client has a fresh copy (or equivalent)". It does not tell us how
Squid came up with that answer, or what Squid has in its cache: We do
not know whether Squid had the corresponding entry cached when the
client request came. If Squid had that entry cached, then Squid may or
may not have tried to validate it. If Squid tried to validate, then
Squid may or may not have gotten an entry from the origin server.
Finally, we do not know whether Squid kept, replaced, or deleted the
cache entry as the result of that validation attempt.

For an extreme example, consider Squid without a cache. Such a
configuration will still have lots of /304 entries in access.log!

A single access.log line (and often even a single Squid result code on
that line!) is telling us what happened when Squid talked to the client
_and_ what happened when Squid talked to the server (if it did talk to
the server). One cannot gain that vital information from a single HTTP
status code alone.


Many folks disagree regarding the best way to structure Squid result
codes. Many also disagree regarding the best definition for "cache hit".
All the different approaches make it very difficult to discuss these
matters and maintain related code. A /304 field alone means the client
got an HTTP 304 response. Whether you call that a "hit" from Squid point
of view depends on your definition of "hit" _and_ (depending on that
definition) on other factors that /304 does not reveal. For example:

* if your definition of a "hit" is "Squid did not talk to the origin
server or peer", then /304 alone does not necessarily mean a hit.

* if your definition of a "hit" is "Squid did not receive a large
response from the origin server or peer", then /304 alone does not
necessarily mean a hit.


HTH,

Alex.

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [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
>  
> >>
>  ...
> >
> > 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@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-



0x613DEC46.asc
Description: application/pgp-keys
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
I do not pretend that I have seen everything.

But my personal statistics across multiple servers over they access.log
shows that TCP_MISS/304 in all cases associated with the update 
downloaded content (reload/refresh). Accordingly, the logging of this
event as a TCP_MISS seems incorrect and, consequently, leads to errors
in accounting/billing. That, in turn, can lead to a loss of money.

So, nice to have functionality for correct handling this cases.

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
 
>>
 ...
>
> 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.
>
>
>>
 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/6OrAAoJENNXIZxhPexG1BIH/jeTUBXJZJemwUN88SU4NCy9
uRDKWbMP0kLW9WEIZnDA3V6TOrIs1u2yLxHHxN4gBPa3vmVf4qSScTZGLRcwB40E
SrdbJnOh6pHFh1qKO4+MdvpmZnjaLW5xmPXbZg8w3kXc+lwUrF3B/LqdblRSytz0
rvrgpTzjPx+SH3gAZ2MD4h7/08rEahmyxrcf3yaf8CMmlBB2Sf2SwY8BWpVROAkG
aCM/XWLssCzmb0U3Mc3STT14p3X0rjgrSni7ISXSfsxpRCT6EkRPukCQmnhm+Q/6
eiUNAVqviVbs7xNPH1oGo3ANTKoDXVKT2tIvytPZ93hBQwg2BuDdVkEIgTEx3p8=
=5YOE
-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

Re: [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
 
>>
 ...
>
> 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

Re: [squid-users] TCP_MISS/304 question

[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
>>> 
> 
>>> ...

 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.


> 
>>> 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

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


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
> > 
>
> > ...
> >>
> >> 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):

 Since the goal of a 304 response is to minimize information transfer
   when the recipient already has one or more cached representations, a
   sender SHOULD NOT generate representation metadata other than the
   above listed fields unless said metadata exists for the purpose of
   guiding cache updates (e.g., Last-Modified might be useful if the
   response does not have an ETag field).

   Requirements on a cache that receives a 304 response are defined in
   Section 4.3.4 of [RFC7234]
.  If the conditional
request originated
   with an outbound client, such as a user agent with its own cache
   sending a conditional GET to a shared proxy, then the proxy SHOULD
   forward the 304 response to that client.

   A 304 response cannot contain a message-body; it is always terminated
   by the first empty line after the header fields.


>
>
> > It might be a CLIENT_IMS_UNMODIFIED or CLIENT_INM_UNMODIFIED if Squid
> > had codes for those cases.
> Ok, Squid has?
>
>
> > 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/5A/AAoJENNXIZxhPexG3NYIAL9pmUn4uAUt2ce9aPu8q/kA
Yeyn5qoCzEhY4Z0bqLFWfyECcQVU1MrcAhhhuRkdPI9zrfVIbF4oa2En4r9jTrUb
nhACmAAq64cYjOIYA9VYzkmiaaPF/ZzSnw+nF9uAwwfUOYP+L0Clg+D4KoywcAqG
0XAOWSasxrc70kFxid17NSMs0/kIIxEek6qhMDbBFKedZoucygIPfgGRX8+cEBQV
8aRdU/M4+HfSNk9sRFcTGUdA44K54z8mOwUDn4axW44M3AOAkDVn1cctaVvYgCLl
NK4Umq0pc0AoF4YoxRRbuXxA6YOvN1CtIhbW8tcYH32Y4dzzcHRdFU9A6kxj8Bw=
=Aulv
-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

Re: [squid-users] TCP_MISS/304 question

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 


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
> 
>
> ...
>>
>> 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?
>
>
> It might be a CLIENT_IMS_UNMODIFIED or CLIENT_INM_UNMODIFIED if Squid
> had codes for those cases.
Ok, Squid has?
>
>
> 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/4/AAAoJENNXIZxhPexGfaYIAMnhMWE2doVT7nsviIavXr8w
T2iOEI/2n1IBDyDYk6+IduuwuaRrt4JtAxTkeOap4Li9nEGtcxL2LNMzUs4fC6sc
4tZ489oI0oz7vR88rx/5jH9ylnXtfx91lERrT4X4KThIuFswp3u++d1yEV37ZjTF
3OnrO46PsveKAqO/qWJXRLh/Gp2X7ohFmNfDSwakFOugjbqDa4XLROf/iygHy08w
q0uLRJLzHDDRYJtTKuvWgY1t7uW/KcHLA31aeN8AYjm4hIFHfS055sFFtry1wczl
H0hFhoGR1cjnMK8KOrzb86pkqukOW68DLGgCJt726WaZUZwf+TAhEn7/q9PlFAY=
=zJff
-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

Re: [squid-users] TCP_MISS/304 question

[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


...
> 
> 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.


> 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.

It might be a CLIENT_IMS_UNMODIFIED or CLIENT_INM_UNMODIFIED if Squid
had codes for those cases.

Amos

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] TCP_MISS/304 question

[Yuri Voinov]

-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

and read:

"


  10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line
after the header fields.

The response MUST include the following header fields:

  - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients
add their own Date to any response received without one (as already
specified by [RFC 2068], section 14.19
),
caches will operate correctly.

  - ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request

  - Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant

If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers. Otherwise
(i.e., the conditional GET used a weak validator), the response MUST NOT
include other entity-headers; this prevents inconsistencies between
cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the
conditional.

If a cache uses a received 304 response to update a cache entry, the
cache MUST update the entry to reflect any new field values given in the
response.

"

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?

My question is:

*Why Squid register this as TCP_MISS/304 in access.log, when logically
expect TCP_CLIENT_HIT/304?*

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJX/4ApAAoJENNXIZxhPexGUO8H/iSYKoMpk2nis3mWF/0Vg58y
2/3+lJaf71RspA8WQ23m4JgqhnmfXF8AlMr/wgvaOCMRTpNumKfL3zhnKd3s4tmq
wXvG562PVHhdBO9gnFK+75PYo1xMe5jdbAHMr+XRzv0ylnBE04rNV+tbpSrRTH2Z
BwZrlDi/Y5UmcPF9zrFIy/6umoeDBkKJHpAlmVwD0krWNmgn2ScquPIQZpoqOgtR
yNGMS7WCAhOF7HGQMaHPsW6RzqwKzWGs6L6pg6CbaE780suncHJqQkq+sY8NgB4k
jZmgH579NiH9f+aVwAjIE7IN+aOv/0XWnT3YfFgeFba03JWu8c5e/oHeFFzhKRE=
=uXt1
-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