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.
