Hello Bertrand, > > > 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.... > > The problem is making the HTTP cache headers variable according to > which pipeline is executed. > > But, in principle, you have to set the headers before any content is > written to the output, and at this point you might not know what kind > of caching you need. > > The way I've been solving this is a follows: > > a) In pipelines, actions or flowscript set request attributes to > indicate what type of caching is needed > > b) A custom transformer at the end of the pipeline sets the HTTP cache > headers according to these request attributes > > Now, you're not supposed to set headers at the end of the pipeline, > but anyway the serializer has to buffer the content to be able to set > the Content-Length header. So nothing is actually written to the > output before b) *if* the serializer returns true for > shouldSetContentType. > > https://issues.apache.org/jira/browse/COCOON-1619 also plays a role in > this, as headers set by internal pipelines are ignored.
Yes, this is kind of a bummer indeed, which I already knew, but do you regard it as a bug (aah reading the bug, you do not seem to really regard it as a bug, me neither)? > > Not sure if this solution can be defined as a best practice, as it's a > bit of a hack...but if works for me ;-) This is actually almost the same "hack" we used, but instead of a transformer a selector, and if some value set in flowscript, an action to set headers. Because we are outsourcing/other parties using our "best practices", and I did not want them to have to think about setting things in flowscript like sessions and values to indicate caching headers, I chose to "put it in the black box" transformer, which handles it. Of course, also kind of a hack, because users aren't really aware of it (certainly because i did not want another sax transformer, so I did add it to the StripNameSpaceTransformer which is by default used by us in front of the serializer. But it does more then its name suggests, and therefor, it is hacky ofcourse. But...at least nobody has to think about it :-) ). I wondered if there was a solid nonhacky solution to the issue.... Ard > > -Bertrand >
