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 wrote:
> I think it worth to add this support even if servlet API is a li
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
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/sp
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 wrote:
> Ok. The feature is not really that important for me, just something
> that would be nice to have.
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 wrote:
> I agree R
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
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
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
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 RF
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 s
10 matches
Mail list logo
