cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Date Wed, 05 Nov 2003 14:33:07 GMT

On Wednesday, Nov 5, 2003, at 14:28 Europe/Rome, Gianugo Rabellino 

> Unico Hommes wrote:
>>> -----Original Message-----
>>> From: Gianugo Rabellino [] Sent: woensdag 5 
>>> november 2003 14:02
>>> To:
>>> Stefano Mazzocchi wrote:
>>>>> setStatus' friends the sendError brothers are also be eligible for 
>>>>> FOM membership. But this change has a dependency on the discussion 
>>>>> about bodyless responses since if you'd do a sendError from a flow 
>>>>> script and then send a page afterwards this would result in >>>>>
>>>> I dislikde "sendError" because, in fact, HTTP does not have the 
>>>> concept of errors, but only status codes and empty-payload
>>> responses.
>>>> In the future, it's entirely possible to have a 309 or
>>> equivalent that
>>>> is not an error, but has a empty-payload response. I would
>>> dislike to
>>>> call "sendError()" to send something that is not an error,
>>> feels hacky.
>>>> I think the optimal solution is:
>>>> 1) add response.setStatus() in FOM
>>>> 2) allow the flowscript to terminate without calling
>>> sendPage* [thus
>>>> resulting in an empty payload]
>>> Sorry to jump in late, I'm probably lagging behind a few posts, but 
>>> was the possibility of having *pipelines* send empty payload 
>>> considered instead? This way flow will always have to sendPage(), 
>>> but the result would be empty content anyway. With the added bonus 
>>> of having the pipeline flexibility to, say, set headers.
>> But the function of a pipeline is specifically towards the production 
>> of
>> an xml response body. To have to set up all the components, execute 
>> the
>> pipeline and then fooling the pipeline to send its data to a null 
>> output
>> or refrain from pipeline execution altogether? In some scenarios that
>> may be necessary, for instance in the case of the http HEAD function.
>> The point is, you shouldn't have to, because there are a lot of
>> situations where its just unneccesary overhead. (for example all the
>> dummy responses in the davmap sitemap)
> I sure can see some use of this. In a few cases (think PUT) you might 
> have XML input flowing through the pipeline (say you might want to 
> transform it) yet you have to send an empty response: in this scenario 
> using a pipeline looks like the best option to me.

I agree that there are situations where it makes sense to go thru a 
pipeline even for potentially emtpy responses, but I also see tons of 
reasons to avoid going thru a pipeline again.

> Also, I feel that the sitemap is core and flow, while being core, is 
> somehow "piggybacked" on the sitemap. I tend to think, then, that 
> deciding whether to send output or not should belong more to the 
> sitemap than to the flow.


The sitemap is core in the fact that the flowscript function is still 
matched there... but deciding the output in case of an empty response 
is a concern of the "programmatical side of things", of the logic that 
"controls the flow" of hte application, not of the logic that drives 
the generation of the payload.

phisolophical issue, I agree, and hardly objective, but the more 
complex the webapp becomes (and webdavapps tend to be *very* complex 
from a flow perspective even for very simple cases) the more stuff 
should be done in the flow (and in java components directly called by 
the flow!) and less in the pipeline.

pipeline should deal with content, flow should deal with headers.

of course, your mileage may vary, but that's a potential design pattern 
that you might want to use to "measure" how you are writing your 

... but this is such a undiscovered land that I might just be dead 

but my gut feeling tells me that webdavapps will have a lot more flow 
than pipelines.


View raw message