cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [VOTE RESULTS] FOM sendStatus/setStatus
Date Fri, 14 Nov 2003 17:27:05 GMT

On 14 Nov 2003, at 18:04, Sylvain Wallez wrote:

> Unico Hommes wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Unico Hommes Sent: maandag 10 november 2003 12:11
>>> To: dev@cocoon.apache.org
>>>
>>>
>>
>> <snip/>
>>
>>
>>> Sylvain Wallez wrote:
>>>
>>>> Furthermore, I would like this feature to be defined at the 
>>>> environment level and not only in the flowscript. Methods of the 
>>>> "cocoon" object should just be wrappers around features available 
>>>> also in regular Java code.
>>>>
>>> These methods already exist on the environment objects:
>>>
>>> See HttpEnvironment.setStatus(), HttpResponse.setStatus() and 
>>> HttpResponse.sendError().
>>>
>>
>> Hmm. It seems I was wrong on two accounts here.
>> First HttpServletResponse.sendError() is specified to send an html 
>> error page.
>>
>> This just means we need to use HttpServletResponse.setStatus().
>> Only problem is the two argument version - 
>> HttpServletResponse.setStatus(int sc, String msg) - seems to be 
>> deprecated with no replacement!
>>
>> The http spec does allow for a customized "reason phrase". So why 
>> this was done remains a mystery to me:
>>
>> -- HTTP/1.1 (RFC 2068) --
>>
>> 6.1.1 Status Code and Reason Phrase
>>
>> ....
>>
>> The reason phrases listed here are only recommended
>>   -- they may be replaced by local equivalents without affecting the
>>   protocol.
>>
>>          Status-Code    = "100"   ; Continue
>>                         | "101"   ; Switching Protocols
>>                         | "200"   ; OK
>>
>> -- /HTTP/1.1 (RFC 2068) --
>>
>> What do you think? Should we skip the two argument 
>> sendStatus/setStatus methods? Or should we ignore the deprecated 
>> warning from the servlet api?
>>
>
> Reading carefully the Javadoc, sendError() and setStatus() are very 
> different:
>
> - sendError() sends an error page and commits the response (nothing 
> more can be sent). The string parameter is the HTML snippet that is 
> displayed in the browser, but not the reason phrase. And this snippet 
> can eventually be overriden if an error page associated to the status 
> code is declared in web.xml
>
> - setStatus() only sets the response status, but does not commit the 
> response, meaning the application can send content afterwards.
>
> And you're right, the servlet API gives us no way to specify the 
> reason phrase (even the deprecated method, in which the string is the 
> same HTML snippet as above). But is it really usefull?

The servlet containers will add the standard HTTP reasons. I don't 
think it's that useful in this case as those error are not meant to be 
human digestible anyway.

--
Stefano.

Mime
View raw message