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