Am 2020-07-06 um 16:04 schrieb Mark Thomas:
On 05/07/2020 10:28, Michael Osipov wrote:
Am 2020-07-02 um 21:30 schrieb Thomas Meyer:
Hi,
What are your opinions on providing a RFC7807 based ErrorReportValve
as part of Tomcat default distribution?
Thomas, this has been bugging me for a while. Let me share some thoughts
on this, I'll limit my experiences with Tomcat, Spring Web and Zalando
Problem (including it's web module):
Mark, please correct me if my citation of the Servlet API is wrong.
* The Servlet API has been designed where the only clients where browsers
I don't think anything in the Servlet API is browser specific. That use
case is certainly supported but I don't think that support is exclusive.
* The Servlet API mandates that all invocations of
HttpServletResponse#setError() must yield in a HTML page and this
*cannot* be changed by defult
I don't recall any requirement to that effect and I can't find anything
looking in the spec.
As for these two, Javadoc says:
Sends an error response to the client using the specified status code and clears the output buffer. 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", leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter.
This is what I see as default.
The requirement is that the error handling mechanism is invoked. Nothing
stops an application providing an error servlet configured to handle all
errors. That could return HTML, JSON, XML, text/plain, etc.
Tomcat's default implementation returns HTML.
Correct, but we are talking about default behavior.
* Even if you write a REST API or explicitly use @RestController Spring
will still invoke #setError() although it makes no sense. I consider
this to be a conceptual flaw in the Spring framework.
Why? That using sendError() just invokes the error handling mechanism.
What matters is what is configured to handle those errors.
Again here, for REST API this doesn't make sense. #setStatus() would be
better here.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
