cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject RE: Not caching pages with continuations (was:...where is 304?)
Date Tue, 30 Jan 2007 11:09:05 GMT


Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
------------------------------------------------------------- /

> -----Original Message-----
> From: Sylvain Wallez []
> Posted At: dinsdag 30 januari 2007 11:42
> Posted To: Cocoon Dev List
> Conversation: Not caching pages with continuations (was:...where is
> 304?)
> Subject: Re: Not caching pages with continuations 
> (was:...where is 304?)

> >   
> Cached responses don't involve the serializer, and this is why the
> headers aren't set. 
> On the contrary, the flowscript is always 
> executed,
> meaning headers will always correctly been set even if the pipeline it
> calls is cacheable (BTW why is this pipeline cacheable at all???)

I indeed already replied on my own remark about caching pipelines involving CForms. Obviously,
when using CForms, these are uncacheable 

> Also, response.setHeader() is ignored for internal requests. Si if the
> flowscript is called through a "cocoon:", headers really have 
> to be set
> on the Http request, accessible in the object model with the
> HttpEnvironment.HTTP_RESPONSE_OBJECT key.

Yes indeed, since the pipeline involving CForms won't be cached anyway, this will work (might
be setting a session/cookie to enable sticky sessions whenever CForms are used also be an
option, to be able to use them in balanced environments? Perhaps configurable because in not
balanced environments it is redundant)

I did have problems in a slightly different setting with HttpEnvironment.HTTP_RESPONSE_OBJECT,
when you want to set for example a 404 status code in an internal pipeline, but still the
entire pipeline can is cacheable. Then, only the first time the response header is set correctly,
but not when fetched later from cache. 

Anyway, for CForms directly manipulating the HttpEnvironment.HTTP_RESPONSE_OBJECT should work
fine indeed because they are uncacheable anyway.


> Sylvain
> -- 
> Sylvain Wallez -
View raw message