cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: More problems with implementing servlet services
Date Sat, 12 May 2007 10:17:11 GMT
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

Mime
View raw message