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.
