cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: More problems with implementing servlet services
Date Thu, 17 May 2007 13:24:37 GMT
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 

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?


View raw message