cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
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 [mailto:gianugo@apache.org] 
>>Sent: woensdag 5 november 2003 14:02
>>To: dev@cocoon.apache.org
>>
>>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 
>>
>>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. 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.

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Now blogging at: http://blogs.cocoondev.org/gianugo/)


Mime
View raw message