[squid-users] Squid 3.5.22 for Microsoft Windows 64-bit is available

2016-10-14 Thread Rafael Akchurin 
Greetings everyone,





Anyone interested in native docker image for Squid 3.5.22 (hopefully soon) on 
Ubuntu 16 LTS?

Please say so and I will publish the Squid on Windows 10/Windows Server 2016 
Docker tutorial here.





The CygWin based build of Squid proxy for Microsoft Windows version 3.5.22 is 
now available (amd64 only!).



* Original release notes are at 
http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.22-RELEASENOTES.html.

* Ready to use MSI package can be downloaded from http://squid.diladele.com.

* List of open issues for the installer - 
https://github.com/diladele/squid-windows/issues



Thanks a lot for Squid developers for making this great software!



Please join our humble efforts to provide ready to run MSI installer for Squid 
on Microsoft Windows with all required dependencies at GitHub -

https://github.com/diladele/squid-windows. Please report all 
issues/bugs/feature requests at GitHub project. Issues about the *MSI installer 
only* can also be reported to supp...@diladele.com.



Best regards,

Rafael Akchurin

Diladele B.V.

https://www.diladele.com



--

Please take a look at Web Safety - our ICAP based web filter server for Squid 
proxy.

___
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

2016-10-14 Thread 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] Squid is not responding when the number of connection exceeds

2016-10-14 Thread georgej 
The server is hosted in VMware



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-is-not-responding-when-the-number-of-connection-exceeds-tp4680091p4680103.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid is not responding when the number of connection exceeds

2016-10-14 Thread georgej 
I can see the number of established connection more than 180 using with below
command.

sudo netstat -nat | grep :8080 | grep ESTABLISHED| wc -l



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-is-not-responding-when-the-number-of-connection-exceeds-tp4680091p4680102.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid is not responding when the number of connection exceeds

2016-10-14 Thread Amos Jeffries 
On 14/10/2016 5:49 p.m., georgej wrote:
> Hi Team,
> 
> When the number of users exceeds, squid is not responding. The users getting
> "System returned: (110) connecion timed out " message.

Exceeds what?

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

2016-10-14 Thread 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

2016-10-14 Thread 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

2016-10-14 Thread 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

2016-10-14 Thread 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

2016-10-14 Thread 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

2016-10-14 Thread 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

2016-10-14 Thread 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] ERROR: Cannot connect to 127.0.0.1:3128

2016-10-14 Thread Михаил 
Hi.Ready. # squidclient -vv mgr:info | head -n 40stub time| WARNING: BCP 177 violation. IPv6 transport forced OFF by build parameters.verbosity level set to 2Request:GET cache_object://localhost/info HTTP/1.0Host: localhostUser-Agent: squidclient/3.5.21Accept: */*Connection: close .Transport detected: IPv4-onlyResolving localhost ...Connecting... localhost (127.0.0.1:3128)Connected to: localhost (127.0.0.1:3128)Sending HTTP request ...done.HTTP/1.1 403 ForbiddenServer: squidMime-Version: 1.0Date: Fri, 14 Oct 2016 10:46:56 GMTContent-Type: text/html;charset=utf-8Content-Length: 3676X-Squid-Error: ERR_ACCESS_DENIED 0X-Cache: MISS from uis-proxy-rop.office.ipe.corpVia: 1.1 uis-proxy-rop.office.ipe.corp (squid)Connection: close ОШИБКА: Запрошенный URL не может быть

Re: [squid-users] TCP_MISS/304 question

2016-10-14 Thread 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