how to set the HTTP reason phrase for 200(OK) in a servlet

[Andy Fish]

Hi,

I am trying to figure out how to return a servlet response with:
- status = 200
- reason phrase - something of my own making (i.e. not the string "OK")
- some content in the body

HttpServletResponse.setStatus(int, String) is deprecated because of
"ambiguous meaning of the message parameter". I'm not sure in what sense it
is ambiguous - I presume it corresponds to the reason phrase and in rfc2616
it says that the default reason phrases are just examples.

I can use sendError to specify a reason phrase which seems to work even for
SC_OK. However, I can't use sendError when including any content in the body
of the response.

so I can't see anything in the HTTP specification that says what I'm trying
to do is wrong, but there seems to be no way of doing it with a servlet.

Thanks in advance for any hints or comments

Andy

 

[John C. Bollinger]

I am trying to figure out how to return a servlet response with:
- status = 200
- reason phrase - something of my own making (i.e. not the string "OK")
- some content in the body

HttpServletResponse.setStatus(int, String) is deprecated because of
"ambiguous meaning of the message parameter". I'm not sure in what sense it
is ambiguous - I presume it corresponds to the reason phrase and in rfc2616
it says that the default reason phrases are just examples.

I presume the anbiguity is between the reason phrase and the message
body. This is a documentation problem, though -- it doesn't seem
appropriate to deprecate the method (with no replacement) just for that.
Or perhaps it has to do with the encoding to be applied to the
message, but that still seems a poor reason to deprecate the method.

I can use sendError to specify a reason phrase which seems to work even for
SC_OK. However, I can't use sendError when including any content in the body
of the response.

That's how it looks to me from the API docs.

so I can't see anything in the HTTP specification that says what I'm trying
to do is wrong, but there seems to be no way of doing it with a servlet.

I concur. HTTP allows a more or less arbitrary reason phrase for any
response, but the servlet API does not appear to offer a non-deprecated
means of delivering a custom reason phrase with a non-error response.


John Bollinger
(e-mail address removed)

 

[Andy Fish]

Just for fun, I tried the deprecated API but it seems to ignore the message
parameter and still sends OK for the phrase :-(

maybe it's time to step back a bit. What I want to achieve is to send more
error information than can be imparted by the HTTP status code (whether it's
success or otherwise) so it can be picked up by a custom client, but I want
to leave the 'friendly' html page in the content for access through a
browser.

I want this to be as transparent as possible to HTTP proxies etc.

Is there an accepted best practice here? should I invent my own HTTP header?

 

[nos]

i think it unwise to do something different from the masses
i suppose you want to change the text in the server log files too
as if debugging isn't already difficult enough

 

[soft-eng]

Just for fun, I tried the deprecated API but it seems to ignore the message
parameter and still sends OK for the phrase :-(

maybe it's time to step back a bit. What I want to achieve is to send more
error information than can be imparted by the HTTP status code (whether it's
success or otherwise) so it can be picked up by a custom client, but I want
to leave the 'friendly' html page in the content for access through a
browser.

Put the extra information in headers. You can define
headers of your own, and browsers will just ignore what
they don't understand.

 

[Andy Fish]

thanks

funny I just asked this very question in a different post.

 

[Chris Uppal]

maybe it's time to step back a bit. What I want to achieve is to send more
error information than can be imparted by the HTTP status code (whether
it's success or otherwise) so it can be picked up by a custom client, but
I want to leave the 'friendly' html page in the content for access
through a browser.

Another approach would be to add the data to the meta tags in the HTML (not
HTTP) header:

<html>
<head>
....
<meta name="MyAppErrorCode" content="AAARGHH!!!!">
...
</head>
.....
</html>

Which would undoubtedly get through the proxies, but might be a pain to parse
(unless you are already parsing the HTML).

-- chris