9

Ok so I have a pretty simple webapp using a Servlet and in some cases I send and error back to the client like:

response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Did not specify parameter xyz");

This works fine in general but Tomcat(6.0.33 and Java 1.6.0_26-b03) does not show the given error message from above.

If I run the application on a different container like glassfish the given message is shown.

So, example output ....

Tomcat:
400 - Bad Request

Glassfish:
400 - Did not specify parameter xyz

Is it possible to configure tomcat to behave in the same way?

rat
  • 2,544
  • 5
  • 21
  • 19
  • Do you have a custom error page set in your project? – Mechkov Nov 17 '11 at 21:12
  • No; no custom error page. It does still show the custom HTML page that tomcat defaults to, and the message I send is visible in there. Glassfish behaves the same way; but it also uses the message as the basic error message that is returned whereas tomcat still uses 'bad request'. – rat Nov 17 '11 at 21:16
  • I was asking because Tomcat 6.0.X had a bug related to failing to send custom messages with "sendError" when a custom error page was involved. – Mechkov Nov 17 '11 at 21:20
  • Hmm, I haven't specified any in my web.xml and I didn't see any in the default web.xml but I'll double check, thanks for pointing that out. – rat Nov 17 '11 at 21:27
  • No problem. Also for further reference check this page...https://issues.apache.org/bugzilla/show_bug.cgi?id=42409 – Mechkov Nov 17 '11 at 21:28

3 Answers3

9

Ok after some more digging I found the solution here: How to properly send an HTTP message to the client

You need to set:

org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = true

in /conf/catalina.properties

This causes tomcat to send the error message you set in the headers 'properly' :)

Community
  • 1
  • 1
rat
  • 2,544
  • 5
  • 21
  • 19
3

Tomcat no longer supports USE_CUSTOM_STATUS_MSG_IN_HEADER property.

Changelog from version 8.5.0:

RFC 7230 states that clients should ignore reason phrases in HTTP/1.1 response messages. Since the reason phrase is optional, Tomcat no longer sends it. As a result the system property org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER is no longer used and has been removed. (markt)

Jarekczek
  • 7,456
  • 3
  • 46
  • 66
0

maybe you would like to create a custom error page, like 400.jsp, and place it in the web.xml as

<error-page>
   <error-code>400</error-code>
.. . path to the page (sorry I don't remember the exact syntax)
</error-page>

On this error page you can obtain this message and show it to user. The benefits of custom error pages is that you can apply your own css styles, your-site-specific markup, etc.

UPD: if you do not like custom err pages: we used this code in RESTful API for sending back to user response with error and message

return javax.ws.rs.core.Response.status(Status.BAD_REQUEST).entity("My message here).build();
javagirl
  • 1,635
  • 6
  • 27
  • 43
  • 1
    A custom error page isn't really the right solution here. The servlet serves a RESTful API so I'm just doing posts to it etc, the user never actually is redirected to an error page. So against tomcat when I get an error back on a POST instead of showing a meaningful message it just gets 'Bad Request' :( – rat Nov 17 '11 at 21:18
  • so what's the problem with redirecting user to the nice error page? it will be done automatically if you specify it in the web.xml, so no any other coding to write – javagirl Nov 17 '11 at 21:22
  • This is an API not a typical website. APIs don't redirect. Other client-applications make RESTful calls to the API and handle the responses appropriately. With tomcat behaving this way they are not getting the correct error messages returned from the API. – rat Nov 17 '11 at 21:28
  • added the update to answer.. sorry for the first misunderstanding – javagirl Nov 17 '11 at 21:41
  • No worries, thx for reply :) We aren't using standard ws stuff so that won't work but I found the setting in tomcat anyways, I knew it must be configurable somewhere! – rat Nov 17 '11 at 21:43