On 29/10/2011 12:51, Amos Jeffries wrote:
On 28/10/11 14:01, Eliezer Croitoru wrote:
1319762961.344 0 192.168.10.32 TCP_MEM_HIT/200 2518 GET
http://www.google.co.il/ - HIER_NONE/- application/xhtml+xml
[Connection: Keep-Alive\r\nHost: www.google.co.il\r\nAccept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,image/png,*/*;q=0.5,
application/vnd.nokia.headwrapper\r\nAccept-Charset:
iso-8859-1,utf-8;q=0.7,*;q=0.7\r\nAccept-Encoding: gzip, deflate,
x-gzip, identity; q=0.9\r\nAccept-Language:
he;q=1.0,en;q=0.5,ar;q=0.5,ru;q=0.5\r\nCookie:
PREF=ID=6fd7cd671b489527:U=61fd668bbde91a39:TM=1308834701:LM=1308834701:S=ys2TW8LoKLm7PDKH;
MPRF=H4sIAAAAAAAAAKu4NqHxwBa1LiaGSUwKpqmJScbJBqlGKUYGiYYGpimpSYYmqUkmKabJRkaW5okTmBkAp8BnhjAAAAA;
NID=52=aDJGrpOOv_UvxjuNWgf-HXZCPM9ZzF60Y6cmk6he2IosV2jBlAtBhSEkXW2NfRGUb5DpaVmpgu7_jgnsZUW-Y-qVw5uITnmJfXrxiokE4LdYgskJcb1Dl3TpqaYizG3j\r\nCookie2:
$Version=1\r\nUser-Agent: Mozilla/5.0 (SymbianOS/9.3; Series60/3.2
NokiaE5-00.2/@version@; Profile/MIDP-2.1 Configuration/CLDC-1.1 )
AppleWebKit/525 (KHTML, like Gecko) Version/3.0 BrowserNG/7.2.6.2
3gpp-gba\r\nX-Nokia-MusicShop-Version: 09.0945.15\r\nPnP:
ver="urn:liberty:PnP:2003-08";
urn:"http://pnpms.nokia.com/signkey"\r\nX-Nokia-MusicShop-Bearer:
WLAN\r\nx-wap-profile:
"http://nds1.nds.nokia.com/uaprof/NE5-00.2r100.xml"\r\n] [HTTP/1.1 200
OK\r\nSet-Cookie:
MPRF=H4sIAAAAAAAAAKu4NqHxwBa1LiaGSUwKpqmJScbJBqlGKUYGiYYGpimpSYYmqUkmKabJRkaW5okTmBkAp8BnhjAAAAA;
expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/;
domain=.google.co.il\r\nExpires: Fri, 28 Oct 2011 00:48:57
GMT\r\nCache-Control: private, max-age=1209600
Bit of a strange header there.
Expires: == Date: -> stale immediately.
"private" - must not be stored.
"max-age=1209600" - permitted to be stored. for up to 14 days
3.2 is supposed to be able to store stale responses. In case the server
goes down and stale response (within max-age) is permitted.
NP: "private" should have prevented that being stored. There seems to be
a new bug there.
I am aware that several caching compliance issues have been raised in
3.2 since SMP went in. Could you verify the cases this occurs and report
please? (after a check that its not reported already of course).
>\r\nDate: Fri, 28 Oct 2011
00:48:57 GMT\r\nContent-Type: application/xhtml+xml;
charset=UTF-8\r\nContent-Encoding: gzip\r\nX-Content-Type-Options:
nosniff\r\nX-Frame-Options: SAMEORIGIN\r\nX-XSS-Protection: 1;
mode=block\r\nServer: GSE\r\nX-Cache: MISS from cachx\r\nX-Cache-Lookup:
MISS from cachx:3031\r\nTransfer-Encoding: chunked\r\nConnection:
keep-alive\r\n\r]
my refresh patterns
#refresh patterns
refresh_pattern -i ^http://www.google.co.il/ 0 0% 0
I know that... i just tried another option of something that might cause
it but the google pattern was cause i dont know the exact code of squid.
for now im working with 3.2.0.5 cause it's the stablest version of 3.2
that i have used.
my friend is using 3.2.0.8 on a production machine as a TPROXY and i
dont like the results.
the .8 version has sometime problem doing dns lookups but it's his
problem finding it out.
im working on a normal way to explain how to use TPROXY on ubuntu 10.04.
i managed to understand how ebtables and iptables are working with
tproxy so i have one virtual machine (part of a network) that is working
as a bridge and TPROXY.
hope to publish the manual of building tproxy bridge machine using
ubuntu from scratch.
(the cases are of a mobile phone browsing the web using the wifi and
after the computer tries to load the page but a "force refresh" is
solving the case most of the time.)
Thanks
Elizer
Matches, but does not have overrides. Cache-Control is present with
specific caching info. So refresh_pattern estimate algorithm limits are
not needed or used.
Amos
