You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael-O <19...@gmx.net> on 2012/11/23 22:09:58 UTC
HttpServletReponse#sendError(int) behavior in ErrorReportValve
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.
Thanks,
Michael
[1]
http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
Am 2012-11-23 23:02, schrieb Mark Thomas:
> 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.
While we are talking about Javadocs, what is the sendStatus supposed to
do? According to the docs the response remains untouched, right?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
Am 2012-11-23 23:10, schrieb Mark Thomas:
> On 23/11/2012 22:07, Michael-O wrote:
>> Am 2012-11-23 23:02, schrieb Mark Thomas:
>>> On 23/11/2012 22:00, Michael-O wrote:
>
> <snip/>
>
>>>> 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.
>>
>> Yes, for the second one. Why do the Tomcat Servlet JavaDocs for
>> sendError(int) not mention that [1]? SendError(int, String) is fine
>> though. Care to update the docs to make this crystal clear?
>
> You started off quoting the Oracle Javadocs and that is what I responded
> to. You are now moving the goal posts. If you think there is room for
> improvement in the Tomcat Javadocs then open an enhancement request and
> provide a patch.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54198
Done, thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Mark Thomas <ma...@apache.org>.
On 23/11/2012 22:07, Michael-O wrote:
> Am 2012-11-23 23:02, schrieb Mark Thomas:
>> On 23/11/2012 22:00, Michael-O wrote:
<snip/>
>>> 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.
>
> Yes, for the second one. Why do the Tomcat Servlet JavaDocs for
> sendError(int) not mention that [1]? SendError(int, String) is fine
> though. Care to update the docs to make this crystal clear?
You started off quoting the Oracle Javadocs and that is what I responded
to. You are now moving the goal posts. If you think there is room for
improvement in the Tomcat Javadocs then open an enhancement request and
provide a patch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
Am 2012-11-23 23:02, schrieb Mark Thomas:
> 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.
Yes, for the second one. Why do the Tomcat Servlet JavaDocs for
sendError(int) not mention that [1]? SendError(int, String) is fine
though. Care to update the docs to make this crystal clear?
Thanks,
Mike
[1]
http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/HttpServletResponse.html#sendError(int)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
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.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
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?
Thanks,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Mark Thomas <ma...@apache.org>.
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
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
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?
Thank you Mark,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by Michael-O <19...@gmx.net>.
Am 2012-11-24 23:08, schrieb Terence M. Bandoian:
> On 11/23/2012 3:09 PM, 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.
>>
>> Thanks,
>>
>> Michael
>>
>> [1]
>> http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29
>>
>>
>
>
> Hi, Michael-
>
> For services that are to be consumed programmatically and do not require
> human-readable content, I would use response.setStatus. Doing so allows
> for a response body, if required, that is appropriate for the associated
> request.
Hi Terence,
this is what I am going to do now but I wanted clarafication on the
sendError(int) method description.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
HttpServletReponse#sendError(int) behavior in ErrorReportValve
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 11/23/2012 3:09 PM, 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.
>
> Thanks,
>
> Michael
>
> [1]
> http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29
>
Hi, Michael-
For services that are to be consumed programmatically and do not require
human-readable content, I would use response.setStatus. Doing so allows
for a response body, if required, that is appropriate for the associated
request.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org