Matus UHLAR - fantomas wrote:
On tis, 2008-07-22 at 23:37 +1200, Amos Jeffries wrote:
Only one issue has come up: under sibling relationships, squids method
of relaying requests to sibling is slightly bad and may break the proper
expected behavior. All other setups should be fine.
On 22.07.08 22:09, Henrik Nordstrom wrote:
Also seen in parent relations.
is that general problem of caching requests with query strings in squid?
I have enabled caching of them long time ago, I hope that would not cause
any problems. Or should I turn on always_direct for those? (I don't have
parent caches)
The problem with query strings, as I understand it, was that originally
no dynamic pages had any Cache-Controls to indicate freshness. Add the
HTTP RFC bandwidth-saving requirements of a required period of caching
to objects unless explicitly denied. And you end up with objects which
both SHOULD and MUST NOT be cached.
The initial fix in squid was the QUERY acl and a blanket dump. Obeying
the MUST NOT over the SHOULD.
Over time many of the dynamic pages have gained proper Cache-Control:
and Expires:. Which is great. Those majority of pages are now cacheable
under a sub-clause, so we decided to make squid allow better HIT rates
and be more RFC compliant, by dropping the QUERY fix.
Unfortunately, there are still dynamic pages (pages in general even)
without Cache-Control: and Expire:.
The backup Squid has these days is the refresh_pattern, which handled
the badness case well for broken dynamic pages as long as the settings
are '0 0% 0'.
Thats broken by the requests coming in from peers, which another Squid
itself has 'fixed' by adding troublesome controls.
So to sum up, caching dynamic pages is usually okay, but there are still
places which are broken and will be user-visible if cached. Peering
squids, will subtly break the expected behavior of these pages by adding
a cache control. I'm not personally convinced its fatal. But its not
good anyway.
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE8
