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?
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? 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.
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.
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.
I want to say that just let's move forward and see how it performs.
--
Grzegorz Kossakowski
