On 23/11/2012 22:00, Michael-O wrote: > Am 2012-11-23 22:50, schrieb Mark Thomas: >> On 23/11/2012 21:44, Michael-O wrote: >>> Am 2012-11-23 22:28, schrieb Mark Thomas: >>>> On 23/11/2012 21:23, Michael-O wrote: >>>>> Am 2012-11-23 22:16, schrieb Mark Thomas: >>>>>> On 23/11/2012 21:09, Michael-O wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've been struggling recently with this builtin valve and some >>>>>>> Spring-based REST services. I some cases I do return states like >>>>>>> 404 or >>>>>>> 400. SendError seems to be the right thing to do but Tomcat >>>>>>> alters the >>>>>>> response with the HTML page. Which is highly unwanted for a REST >>>>>>> API. >>>>>>> >>>>>>> I have checked Oracle's original JavaDocs for #sendError(int) + >>>>>>> Servlet >>>>>>> Spec 2.5 and 3.0 all three of them, do not explicitly mention >>>>>>> that an >>>>>>> error HTML response is returned with this method. The JavaDoc [1] >>>>>>> says: >>>>>>> "...If an error-page declaration has been made for the web >>>>>>> application >>>>>>> corresponding to the status code passed in, it will be served >>>>>>> back the >>>>>>> error page..." >>>>>>> >>>>>>> I did not define a custom error page. >>>>>>> >>>>>>> Where as the #sendError(int,String) says: >>>>>>> "... The server defaults to creating the response to look like an >>>>>>> HTML-formatted server error page containing the specified message, >>>>>>> setting the content type to "text/html"." >>>>>>> >>>>>>> This one is crystal clear. >>>>>>> sendError(int) simply calls sendError(int,String) with a null string >>>>>>> arg. >>>>>>> >>>>>>> Am I misunderstanding the the definition? Should I avoid sendError >>>>>>> alltogher and resort to setStatus? What would be the implications? >>>>>>> I do know that sendError commits and closes the response >>>>>>> immediately. >>>>>>> >>>>>>> A clarification is highly appreciated. >>>>>> >>>>>> Use Tomcat 7 and define a custom, default error page. You'll then >>>>>> remain >>>>>> in complete control of the error response. >>>>> >>>>> Well, I am still on Tomcat 6 but I would do the following: >>>>> >>>>> 1. Define a @Controller >>>>> 2. Define @RequestMapping on a method >>>>> 3. Map that controller in the web.xml >>>>> >>>>> Now here's the problem, that method would return ModelAndView or >>>>> simply >>>>> a view's string name. But I would like to use ResponseEntity as it >>>>> would >>>>> be necessary for REST. >>>>> >>>>> Did you had this in mind? Otherwise would "produces" with distinct >>>>> methods work for such an error page? >>>> >>>> Sorry, I know next to nothing about Spring (and yes, I do work for >>>> SpringSource). >>>> >>>> For Tomcat 6 I'd define my own error valve but that is not portable. >>>> You >>>> could also define error pages for each error code you use and for >>>> java.lang.Exception >>> >>> The problem is that our Tomcat is serving a variety of apps. I do not >>> want to code a custom valve to one app which would impact other ones. >>> Neither I do want to subclass StandardHost class and disable the valve >>> and add one on a per-webapp base. >>> >>>> My reading of the specification text quoted above is that the server is >>>> expected to create HTML error pages unless the user defines a custom >>>> error page in web.xml. I don't see any room for an alternative >>>> interpretation. >>> >>> Well, that applies for the JavaDoc of sendError(int, String). >>> sendError(int) does not say that the server has to auto-generate a HTML >>> error page unless one is defined by the developer. >>> Am I correct? >> >> No. >> >> sendError(int) == sendError(int, null) >> >> sendError(int, null) requires an HTML response, even if the message is >> null. > > I am aware of that implementation detail. I was solely referring to the > definition in the JavaDocs. They seem to be misleading. At least to me.
I was referring only to the Javadoc you quoted. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
