Grzegorz Kossakowski wrote:
Vadim Gritsenko napisał(a):
Grzegorz Kossakowski wrote:
IMHO, Cocoon *should* handle *external* HTTP HEAD requests
automatically -- build a pipeline, but not execute it -- and do it for
all types of sitemap, including those which have actions or
flowscripts -- so that application writer can explicitly handle these
cases, as Daniel said above. Yes, documentation and warnings would be
nice.
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.
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.
But, I am not so sure that this same mechanism should be reused in the
context of this service machinery -- some other option discussed
earlier in this thread is IMHO more appropriate here, be it passing
some environment or call stack or whatever is required (yep, you can
tell I was not following this thread too closely ;-)
For some reason I do have an expectation that "service" would work
seamlessly with any sort of sitemap, passing in data from original
request unchanged. Imagine for a second that the sitemap you are
calling *is* aware of the HTTP method, and its response depends on the
method. In this case, if you change request method -- say original
method was PROPSET or LOCK -- and use HEAD instead of LOCK, the
sitemap you are calling could give completely unexpected result (e.g.
error page :).
You are right here but how it's different from current situation with
buffered vs not buffered output?
I don't see any connection of the above with unbuffered output?
Calculation of status code is done in
setup phase then if you have not buffered output stream and something
bad occurs during actual processing (so exception is thrown) you are
going to have a real trobule - broken resposne.
That is the price you are prepared to pay if you *HAVE TO* have unbuffered
output. An alternative to unbuffered output usually is a (almost guaranteed)
OutOfMemoryError. What would you pick -- OOME in 99% of requests or broken
response in 0.01% of requests?
I guess the same applies to the current situation. For most of the time,
simple handling of HEAD method will just work, in more sophisticated
scenarios it's up to developer to handle all the cases.
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.
I'm not in favor of any solution because all of them have shortcomings.
What Daniel proposed is the less invasive solution and can be
implemented very easily so I'll go for it.
What is this solution?
Vadim
