Sometimes (only sometimes!) HTTPD forwards requests "If-Modified-Since" from Internet Explorer to Cocoon. Without 304 we will never have cache!
When I say "sometimes" I mean that few different caches exists at HTTPD, per-process. We may have 32 processes, 128 threads each, total: 32 caches with memory limitations. That was true with previous v.2.0.44 and experimental mod_cache. If HTTPD does not have cached page (due to LRU), it will forward to Cocoon with "If-Modified-Since" (which originally came from Internet Explorer, or from another corporate proxy). Cocoon must reply with 304. Additionally, existing HttpCacheAction create new Expiration header for each request. So that 32 caches at HTTPD will be out-of-sync (same page, but different expiration). All this is from my old experience, I tested it 4 years ago with WebLogic 7 and Apache HTTPD 2.0.44... It works now with some very small amount of additional code, very attractive (thanks to Cocoon!) Thanks, Fuad. -----Original Message----- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Monday, January 29, 2007 1:39 AM To: [email protected] Subject: Re: FW: HTTPD mod_cache HttpCacheAction: where is 304? On 1/28/07, Fuad Efendi <[EMAIL PROTECTED]> wrote: > Following to > http://wiki.apache.org/cocoon/ControllingModCache > > I found this class: org.apache.cocoon.acting.HttpCacheAction (dated > 2004-07-29) > > Unfortunately, this action can't reply with 304 on request with HTTP Header > [If-Modified-Since: ......].... The idea is that the httpd front-end would handle that case: if a page has been cached by the httpd front-end, conditional GETs will not hit Cocoon until the httpd cache expires. So yes, you could say that there's no caching between httpd and Cocoon in this case. But this doesn't prevent you from using Cocoon's internal caches in pipelines, if you need to. -Bertrand
