I agree Ross... I would be very reluctant to have Lift rely on some deprecated 
method in the servlet spec - even if it is in servlet 3.0.

Cheers, Tim

On 7 Feb 2010, at 20:48, Ross Mellgren wrote:

> Yeah you're very correct. It's unfortunate, but I think since it's deprecated 
> in the container we should probably not add support for it. I can't believe 
> they deprecated it for the reason they did, but there it is.
> 
> -Ross
> 
> On Feb 7, 2010, at 8:16 AM, Erkki Lindpere wrote:
> 
>> Actually, the reason phrase is not a normal HTTP header, but part of
>> the status line:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1
>> 
>> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
>> 
>> Examples:
>> HTTP/1.1 200 OK
>> HTTP/1.1 404 The user with id 8 does not exist
>> 
>> The only way of setting this in Java Servlets as far as I know is
>> through HttpServletResponse.setStatus(int, String), which
>> unfortunately is deprecated. A non-deprecated possibility is
>> sendError(int, String), but that goes to the container's default error
>> page (or the one defined in web.xml, I think) so it's not exactly what
>> I would like.
>> 
>> Also, I checked that FireBug actually does display the custom reason
>> phrase, but Chrome displays the standard one instead.
>> 
>> Erkki L
>> 
>> On Feb 7, 1:08 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
>>> If you want to alter the Reason-Phrase, you can already do that - objects 
>>> like NotFoundResponse are just helpers on InMemoryResponse... nothing 
>>> stopping you adding your own helpers that set headers with customised 
>>> reason codes; this should give you what you what. I haven't managed to find 
>>> an RFC that lists reason-phrase as anything but a particular header in the 
>>> HTTP response.
>>> 
>>> Moreover, its not the wrong thing to return a plain text response if the 
>>> request mime was text/plain... indeed, it would be even less helpful if it 
>>> returned JSON or such. IMHO, the response type should match what was asked 
>>> for by the caller - i.e. its an implementation issue not a framework level 
>>> issue.
>>> 
>>> Tim
>>> 
>>> On 6 Feb 2010, at 21:55, Erkki Lindpere wrote:
>>> 
>>>> The NotFoundResponse (and others) puts the custom message into the
>>>> request body. That works as well, but to be really lean (mainly for
>>>> bragging rights :)) I'd like to remove any unnecessary elements from
>>>> the rest api. Most of the error messages are going to be simple one-
>>>> line messages (and short sentences). For some errors I might provide a
>>>> detailed response and it could go into the body, as XML/JSON/...
>>>> That's inconsistent if the other errors have a plain text message in
>>>> the body.
>>>> So I could either go with structured details for all messages or in
>>>> simple cases use the HTTP headers or status line. A custom header
>>>> would work, but the status line is standard and also more easily
>>>> accessed with some client libraries.
>>> 
>>>> And last but perhaps not least, for debugging purposes, the HTTP
>>>> Reason Code should show up better in web developer tools (for example
>>>> FireBug, Chrome's tools). My web UI also goes through the REST API so
>>>> it would be nice to read error messages right in the listing in
>>>> firebug's net panel.
>>> 
>>>> So I'm suggesting that perhaps Lift would like to provide only the
>>>> possibility of changing that value in user code. But I completely
>>>> understand if it doesn't. Currently it doesn't seem to be supported in
>>>> Lift's http.provider package and even in javax.servlet the
>>>> setStatus(int, String) method is deprecated (I'm not sure if
>>>> sendError(int, String) uses the reason phrase).
>>> 
>>>> Erkki L
>>> 
>>>> On Feb 6, 9:59 pm, Ross Mellgren <dri...@gmail.com> wrote:
>>>>> I think it would be fine to have different text there, probably better 
>>>>> than having the standard text if you have refined detail. I don't think 
>>>>> it'd be a good idea to conditionalize on the response text in client code 
>>>>> - that's always fragile. If you want to give additional machine-readable 
>>>>> detail, I'd put it in a response header or in the body as a JSON or XML 
>>>>> field or what have you.
>>> 
>>>>> You can specify custom text there, but you may have to sidestep the usual 
>>>>> response classes, depending on which one. The one you gave, not found, 
>>>>> can have the message customized though, just do new NotFoundResponse("the 
>>>>> message").
>>> 
>>>>> -Ross
>>> 
>>>>> On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote:
>>> 
>>>>>> It seems Lift does not support custom HTTP Reason Phrases in
>>>>>> responses. I would like to send error messages in the Reason Phrase
>>>>>> (along with a vaguely applicable HTTP status code) in a RESTful API
>>>>>> I'm providing. My understanding of the HTTP spec is that the reason
>>>>>> phrase is meant to be human readable and does not have to contain the
>>>>>> recommended messages (i.e. "Not Found").
>>> 
>>>>>> But maybe it would not be wise to do this? I'm not actually aware of
>>>>>> any API-s that send error messages in the Reason Phrase.
>>> 
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google 
>>>>>> Groups "Lift" group.
>>>>>> To post to this group, send email to lift...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to 
>>>>>> liftweb+unsubscr...@googlegroups.com.
>>>>>> For more options, visit this group 
>>>>>> athttp://groups.google.com/group/liftweb?hl=en.
>>> 
>>>> --
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "Lift" group.
>>>> To post to this group, send email to lift...@googlegroups.com.
>>>> To unsubscribe from this group, send email to 
>>>> liftweb+unsubscr...@googlegroups.com.
>>>> For more options, visit this group 
>>>> athttp://groups.google.com/group/liftweb?hl=en.
>>> 
>>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Reply via email to