It took me sometime to find this email until a friend pointed it out. You brought up the point that we have been trying to solve by not caching the site. Here is the full story. There is a site behind our Reverse Proxy that keeps on getting funky due to missing icons and some pages that does not follow the formatting. Looking into this issue, we realized that even if we configured our HTTP Headers not to cache this site, I still find instances of that site in the cache during purging. This is what started this post. We have compiled our Apache to use mod_auth_session to assist in security of the site. What you have provided below seems to have pointed us to resolving this issue. "The redirection just has a "Cache-Control: max-age=0", which allows the cache to store the response, and just requires that it be revalidated (which is done as evidenced by the TCP_REFRESH_HIT in the Squid log)." It seems that when the responses got stored, the authentication gets funky and in effect some objects referenced in the page cannot be access. We will modify our mod_auth_session code to avoid this condition. If neither the recoding of mod_auth_session nor adding the "cache deny" directives does work, I will update this post. Thank you so much, Chris. Regards, Jerome -----Original Message----- From: crobertson@xxxxxxx [mailto:crobertson@xxxxxxx] Sent: Tuesday, June 10, 2008 1:12 PM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: How to not cache a site? Jerome Yanga wrote: > Resending as I had received a failure notice message. > > I do not think that the refresh_pattern is even setup as they are all > commented out. > > # grep refresh_pattern /etc/squid/squid.conf > # refresh_pattern regex min percent max > #refresh_pattern -i \.js$ 0 0% 1 > #refresh_pattern -i \.css$ 0 10% 30 > #refresh_pattern . 0 20% 4320 > > Attached is a zipped http header log captured using Live HTTP Headers. > > Regards, > Jerome > Sample squid log entry from the zip file (without cookies) for reference: ------------------------ TCP_REFRESH_HIT:FIRST_UP_PARENT 10.11.12.13 10.10.10.10 - - [06/Jun/2008:21:42:52 +0000] "GET http://site_address.com/help/chr_ind_on.gif HTTP/1.1" 302 830 "http://site_address.com/help/whskin_tbars.htm"; "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14" ------------------------ There were no associated HTTP headers for this object (http://site_address.com/help/chr_ind_on.gif)*, but here is another request that also resulted in a 302 (Moved Temporarily): ------------------------ GET /help/chr_back.gif HTTP/1.1 Host: site_address.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Accept: image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://site_address.com/help/whskin_tbars.htm Cookie: [removed] HTTP/1.x 302 Moved Temporarily Date: Thu, 05 Jun 2008 23:40:54 GMT Location: http://site_address.com/gateway/index.cfm?fa=login&returnURL=http%3A%2F% 2Fsite_address%2Ecom%2Fhelp%2FFchr%5Fback%2Egif Cache-Control: max-age=0 Expires: Thu, 05 Jun 2008 23:40:54 GMT Content-Length: 422 Content-Type: text/html; charset=iso-8859-1 Connection: keep-alive ------------------------ The redirection just has a "Cache-Control: max-age=0", which allows the cache to store the response, and just requires that it be revalidated (which is done as evidenced by the TCP_REFRESH_HIT in the Squid log). So, I'm still not seeing anything being cached against the server's request. Try tailing the access log and grep for " 200 " and "HIT"** (note the spaces on either end of the 200). That should show any objects (as opposed to redirects or errors) that are served from cache. Chris * The other URL (http://site_address.com/help/whskin_tbars.htm) it the referrer. ** tail -f /cache/logs/access.log | egrep "10.10.10.10.* 200 .*HIT"
