cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject RE: FW: HTTPD mod_cache HttpCacheAction: where is 304?
Date Mon, 29 Jan 2007 09:11:53 GMT

now we are talking about httpd mod_cache already, is there any best practice to have cforms
in urls you do not know on beforehand, with continuations? For high-traffic sites, we obviously
want to use mod_cache, but, at the same time, mod_cache shouldn't cache pages with a continuation
in it. Since we don't know which urls these are, we cannot configure some urls(parts) in mod_cache
not to cache. To make it even more complex, a continuation should always return to the same
cocoon instance in a balanced environment. 

Is there a common best practice on this? You can not just say in the cforms part matcher,
to set headers, because you must set the headers the "main" matcher, from which the serializer
is used. The only (poor) solution I could come up with, is a SAX transformer that looks for
an action that end with ".continue", or een input with a name="continuation-id". If it finds


are set, and if the cookie map of the request is empty for sessionhost, I add a cookie to
the response, to enable sticky session for a load balanced environment. 

Well, clearly, since I assume things like action ending with ".continue" or an input element
with some name, I made some assumptions (of course, could make it configurable). I choose
this solutions, because third parties are implementing projects as well, and I do not want
them to have to think about headers and sticky sessions. 

In short, did other people have had this same requirements, and is there some best practice

Regards Ard

> On 1/28/07, Fuad Efendi <> wrote:
> > Following to
> >
> >
> > 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
View raw message