On Mon, 3 Oct 2011 18:19:28 -0700 (PDT), Manuel wrote:
> Any idea of what can be the problem or at least any advice on what to 
> try or
> how to find the problem?
>
> BTW is Squid 2.6.STABLE21 with override-expire ignore-reload 
> ignore-private
 The problems could be that you are:
  1) ignoring the cache expires header. Causing objects stored not to 
 expire properly and not to get updated when they are changed.
  2) ignoring the 'private' header. Causing objects which are generated 
 for private use by exactly one user to be stored and shared between 
 multiple visitors. Very, *very* dangerous with a forum where personal 
 account pages are almost certain to exist at shared URLs (including your 
 administrative login views!).
  3) ignoring the reload controls. Which servers use to inform caches 
 that the objects are outdated and need replacing. And which clients use 
 to manually force reloading of a page when they can clearly see a broken 
 problem on the page caused by (1) and (2), ie missing CSS, wrong images, 
 missing posts, private data from someone elses account, etc.
 Or since Squid caches only one variant at a time. It could be this very 
 common scenario:
  client A accepts gzip, contacts Squid and gets the gzip version to 
 cache. Your rules seek to cache it for a long time. Everything looks 
 fine.
  Then client B comes along who requests a different encoding than gzip. 
 One of two things happen at this point. First is that if Vary was not 
 set right client B could get given the gzipped content marked as 
 non-gzip (this is the broken_vary problem that directive exists to 
 avoid). Alternatively, Squid detects the different encoding requirements 
 and passes the request back for that new variant of the page object.
  It is common that the client B is some application (robots!) which 
 requests no encoding. This is a form of encoding which all clients can 
 accept, and most importantly it usually appears with no Vary: header 
 telling Squid to check for encoded versions. So Squid gets that and 
 stores it for a very long time and serves it to everybody, no gzip. You 
 can only avoid this by having your web server send "Vary: 
 Accept-Encoding" header on all replies, even the non-encoded ones.
 Amos
Received on Tue Oct 04 2011 - 02:03:42 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 05 2011 - 12:00:02 MDT