[squid-users] TCP_MISS/304 question

Fri Oct 14 13:05:55 UTC 2016

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/s    in
>>> 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/s    in
>>> 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 3 and 4 latest Google Chrome used. No MSIE bullshit, which
> is not respect RFC at all.

That is why I said "copied by the others". The F5-thing comes from
Visual Studio hotkeys I think, it was a more recent addition.

> 
> Anyway. This is word games.

Games? no. Technical terminology is never a game. Getting it right is a
critical requirement for communication and understanding the technical
concepts/operations.
Like I said the browser button name seems to have confused your
understanding of the HTTP term usage. Which are different.

> 
> The HTTPS object (HTTP/1.1) is absolutely sure in client and proxy
> caches. Right?

It was before, yes. It also is after, yes.

But the two refresh and force-refresh requests placed different
revalidation requirements on what Squid could do. Thus what happened was
different, and that alters the tags that get logged to say what happened.

> 
> So, why not expired object in both caches produces TCP_MISS/304?
> 

I think the situation here is that Squid is still doing the HTTP/1.0
behaviour when the CC:no-cache request header is received. The response
CC:no-cache handling was corrected, but the request handling has not
been updated yet.

Under HTTP/1.1 (RFC 7234 version) it should only force revalidate to
happen. But in HTTP/1.0 it forced the cache to be ignored. That needs
fixing.

In terms of bugs this is a missing feature / enhancement issue. It is an
acceptible response within HTTP/1.1 (so not major bug), but better
bandwidth uses are possible.

Amos