Opened ticket: https://www.assembla.com/spaces/liftweb/tickets/334-Support-for-HTTP-Reason-Phrase
In case you are busy with other things, I might have time this weekend to create a patch. Erkki L On Feb 8, 9:23 pm, Marius <[email protected]> wrote: > I think it worth to add this support even if servlet API is a little > weird sometimes but Lift HTTP API could provide a nicer support. > Furthermore such Lift API support would be handy for non JEE > containers therefore I'd vote for it. > > Erkky would you please open a defect (https://www.assembla.com/spaces/ > liftweb/tickets) and assign it to me ? > > Br's, > Marius > > On 8 feb., 21:08, David Pollak <[email protected]> wrote: > > > I think this issue rests with Marius. He's done most of the interface > > between Lift and the servlet containers. Let's see what he has to say. > > > On Sun, Feb 7, 2010 at 2:47 PM, Erkki Lindpere <[email protected]> wrote: > > > 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]<liftweb%[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]<liftweb%[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]<liftweb%[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]<liftweb%[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]<liftweb%[email protected] > > > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/liftweb?hl=en. > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Surf the harmonics > > -- 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.
