Ah yes - keep forgetting one day we'll have netty et al providers! Interested to see what you come up with Marius
Cheers, Tim On 8 Feb 2010, at 19:23, Marius 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 <feeder.of.the.be...@gmail.com> 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 <vill...@gmail.com> 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 <timo...@getintheloop.eu> 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 <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<liftweb%2bunsubscr...@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<liftweb%2bunsubscr...@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<liftweb%2bunsubscr...@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<liftweb%2bunsubscr...@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<liftweb%2bunsubscr...@googlegroups.com >>> > >>> . >>> 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 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.
