Ok. The feature is not really that important for me, just something that would be nice to have. I think some hack could be made with sendError(int, String) and web.xml config, but that would be worse than using the deprecated method.
Erkki L On Feb 7, 11:20 pm, Timothy Perrett <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 [email protected]. > >>>>>> To unsubscribe from this group, send email to > >>>>>> [email protected]. > >>>>>> 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 [email protected]. > >>>> To unsubscribe from this group, send email to > >>>> [email protected]. > >>>> 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 [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
