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. 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. > * 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
