On Thu, 6 Dec 2001, Paul Lindner wrote: > On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote: > > At 08:19 AM 12/06/01 -0800, Paul Lindner wrote: > > > > Ok, hit me over the head. Why wouldn't you want to use a caching proxy? > > Apache::CacheContent gives you more control over the caching process > and keeps the expiration headers from leaking to the browser. Or > maybe you want to dynamically control the TTL?
You can use mod_accel to cache flexible backend: ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_accel-1.0.7.tar.gz mod_accel understands standard "Expires" and "Cache-Control" headers and special "X-Accel-Expires" header (it is not sent to client). Besides it allows to ignore "Expires" and "Cache-Control" headers from backend and set expiration by AccelDefaultExpire directive. Comparing to mod_proxy mod_accel reads backend response and closes connection to backend as soon as possible. There is no 2-second backend lingering close timeout with big answers and slow clients. Big answer means bigger then frontend kernel TCP-send buffer - 16K in FreeBSD and 64K in Linux by default. Besides mod_accel read whole POST body before connecting to backend. mod_accel can ignore client's "Pragma: no-cache", "Cache-Control: no-cache" and even "Authorization" headers. mod_accel allow to not pass to backend some URLs. mod_accel allow to tune various buffer size and timeouts. mod_accel can cache responses with cookie-depended content. mod_accel can use busy locks and can limit number of connection to backend. mod_accel allows simple fault-tolerance with DNS-balanced backends. mod_accel logs various information about request processing. mod_accel can invalidate cache on per-URL basis. mod_accel has two drawbacks only - too much memory per connection (inherited Apache drawback) and Russian only documentation. Igor Sysoev
