cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Date Wed, 05 Nov 2003 13:28:41 GMT
Unico Hommes wrote:
>>-----Original Message-----
>>From: Gianugo Rabellino [] 
>>Sent: woensdag 5 november 2003 14:02
>>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 errors.
>>>I dislikde "sendError" because, in fact, HTTP does not have the 
>>>concept of errors, but only status codes and empty-payload 
>>>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. 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.


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Now blogging at:

View raw message