Grzegorz Kossakowski wrote:
Vadim Gritsenko pisze:
Grzegorz Kossakowski wrote:
Vadim Gritsenko napisał(a):
For pipelines consisting of only generators, transformers and
serializers it's really easy to implement (I have a patch for it
already done). However, how do you see it could be implemented
*automatically* for actions and flowscripts?
IIRC, tree processor can happily build a pipeline even if there are
actions in the sitemap - so that is not a problem.
I don't get these. Action has only one method act() where e.g. database
operations and status code can be mixed. If we call act() during
processing of HEAD request we will have side effects (db operations)
Exactly! And this is good - because this is expected.
(Here we are talking in the context of external requests).
otherwise we will not have a proper value of status code that we are
supposed to return in response to the HEAD request.
The only option I see is handling HEAD request inside act() by author of
action but this we can't call it an automatic handling of HEAD requests
for actions ;)
There is a multitude of ways for application authors to handle this, and one of
those is matcher/selector on request method.
A bit different with the flowscript. In case of a flowscript, tree
processor result will be one of:
* empty response with status code
* internal redirect
* redirect
In case of internal redirect you'd have to follow it to build the
actual pipeline.
Right, but what about other operations performed in flowscript?
These are expected to be performed. Same as with actions.
Flowscript would have to be written in conditional manner so it does not
perform any operations while handling HEAD request right?
Yes of course.
It's the same as for actions, there is no automation here. May it be
that you have other idea?
My idea is that Cocoon should simply correctly handle HEAD requests, and the
rest should be left to documentation and application developer.
I don't see any connection of the above with unbuffered output?
I was referring to the error page when LOCK is called.
You probably missed the point in the first paragraph you quoted.
That's what I said -- Cocoon should handle HEAD requests,
automatically, for external HEAD requests.
However, that should not be done in the context of services *creating
internal* HEAD requests while original HTTP request was something
different -- that would break any program, even specifically written
for such quirks. This is described in 2nd and 3rd paragraph you quoted.
Yes, I missed your point. If we don't use internal HEAD requests
Yes that would be my preference.
Vadim
the only option is Daniel proposal (hack).
What is this solution?
See: http://article.gmane.org/gmane.text.xml.cocoon.devel/73261
