Re: RFC7807 ErrorReportValve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 7/6/20 09:58, Mark Thomas wrote:
> On 03/07/2020 20:42, Thomas Meyer wrote:
>> Am 2. Juli 2020 21:45:53 MESZ schrieb Mark Thomas
>> :
>>> On 02/07/2020 20:30, Thomas Meyer wrote:
Hi,
What are your opinions on providing a RFC7807 based
ErrorReportValve
>>> as part of Tomcat default distribution?
>>>
>>> RFC 7807 looks to be application specific so support for that
>>> RFC looks to be better handled at the application level.
>>
>> Mhh, okay, sad to hear.
>>
>> The basic idea was to provide an ErrorReportValve that always
>> responds with an JSON, given the use case that tomcat is
>> sometimes used purely as an HTTP JSON based API server, aka.
>> REST, this Valve would always return an JSON object and not
>> suddenly an HTML page if for any reason something goes horrible
>> wrong.
>>
>> It would be a nice to have for tomcat to provide an out of the
>> box support for this use case.
>>
>> But yes the format of the JSON is hard to define generally, above
>> RFC was one of the first search results :-)
>
> If there was something that could be done generically at the
> container level then I'd have no objection but it doesn't look like
> RFC 7807 is a good fir for that.
I think maybe this can be done without too much trouble, as long as
it's possible to replace / augment he existing ErrorReportValve on a
per-context or per-accept-header basis. If the context explicitly uses
an RFC 7807 error-reporting valve, it would obviously behave as below,
but I'm thinking about e.g. context-is-not-deployed errors where the
ROOT context will be replying instead of the actual application, or
where a 4xx response is required where the application itself may not
be involved.
If the ROOT application is replying, it might be nice for it to behave
as the client expects. If the Accept header prefers application/json
as a response Content-Type, perhaps the RFC 7807 reply could be provided
.
Using the example from Section 3 of the RFC, it wouldn't be difficult
for Tomcat to emit the following:
HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en
When e.g. 403 will be returned. The question is what to do next. If
the application sets maybe a special request parameter like
"org.apache.catalina.error-details" which is Map, we
could just emit:
{
"key" : "value",
..
}
For all items in the map.
Perhaps if the map is not present / empty, some generic details could
be added such as:
{
"status" : "[HTTP status code]",
"title" : "[exception detail message]",
"detail" : "[exception stack trace]"
}
Why build this in to Tomcat? It would allow users to configure a ROOT
context such that no application-specific code would be required.
I have a REST-ish application which uses XML and have to go through
some hoops to ensure that the clients always get an XML response
instead of HTML. This kind of thing would be very nice.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8EgFgACgkQHPApP6U8
pFiJJhAAuN12V3+SAhJgzuY/nsHgMpHuopWAKyDnxHE2g07/xQlLHOJCjvrfP3ic
Z5KSwA9ouIsIvh3hmf0AyQTr+PgVZRIs8HHV3Ymk4S0+p/7DaQBe8enc+H+RO1Iz
CMhcU+Fs8zQJwrH8e35kdiEgE9pBd79WaB/mouSCmAA33s/6Lmw2yYFgRGrwM1c6
WzMxtJrtrQRcOWvuST89Zs119jhWxPE0+9IKVTOBlSeCymdtLettWoSm4D96CxNh
FyIqk1HKnPIxYxveg+Ekoa8TNGFrJo9LHBO9jFcRbW75Mp3LePFjx1O64XJSvQjD
7z74RvlL03j5TOf+/2A3ucjQfqGoUSvuSMeZbKKfB8BH9jd6K++e+zgLDQMLyOvb
NNgcFZF+kPdWWsi5JNKF4mkdwcIQI4s8EJV3v/JDOR5CMTTOy9OVCMyu/ju9N3dy
t/r16r59mC8/rqhfuCMNpRWJKeWQRtCPBLFu0BegvRTvX1OME8VcUU3ScbwEuDOe
u+h9jUzZNnjhWosJwn98z8UbYJ/4vILexZR2s5deIlXJtFTggsCU1UobGneZGvJu
C7DHy4E9DPIafDEWBTl0Qqc3GQlSEkMvrzDnhsvyEtsPz3qxkKMUQNl1HzihjAN9
44fyO6e9OGzB8dAkjIvJbroBOezqWkLBH9H/me5OsgTTJfQaODM=
=M9Ul
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RFC7807 ErrorReportValve
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
Re: RFC7807 ErrorReportValve
Am 5. Juli 2020 11:28:40 MESZ schrieb Michael Osipov : >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 >* The Servlet API mandates that all invocations of >HttpServletResponse#setError() must yield in a HTML page and this >*cannot* be changed by defult >* 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. > >Before we continue which issue do you want to solve? Tomcat produced >errors or by a framework? It's about tomcat produced errors: There are multiple webapps deployed to tomcat all under non-root context path. Some webapps use spring framework, for these webapps an CustomErrorController is installed so always a JSON response in a given JSON layout is done. Some webapps are pure servlet based, here an error-page entry in web.xml and an ErrrorSerlvet is used to also have the same JSON layout as above for all possible errors. But because of some race condition in deployment scripts for multi node setup, some class files weren't copies correctly, and tomcat ErrorReportValve was triggered with NoClassDef error. So much for the context. I guess I'll write an JsonErrorReportValve and install it in lib/ so deployment will always response with same JSON layout in all circumstances, e.g. failed deployment or access to unknown context path. > As for the framework, I would prefer to file > >an issue with Spring Framework first and see what the devs say because >this would solely solve a symptom. > >Michael > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RFC7807 ErrorReportValve
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
Re: RFC7807 ErrorReportValve
On 03/07/2020 20:42, Thomas Meyer wrote: > Am 2. Juli 2020 21:45:53 MESZ schrieb Mark Thomas : >> On 02/07/2020 20:30, Thomas Meyer wrote: >>> Hi, >>> >>> What are your opinions on providing a RFC7807 based ErrorReportValve >> as part of Tomcat default distribution? >> >> RFC 7807 looks to be application specific so support for that RFC looks >> to be better handled at the application level. > > Mhh, okay, sad to hear. > > The basic idea was to provide an ErrorReportValve that always responds with > an JSON, given the use case that tomcat is sometimes used purely as an HTTP > JSON based API server, aka. REST, this Valve would always return an JSON > object and not suddenly an HTML page if for any reason something goes > horrible wrong. > > It would be a nice to have for tomcat to provide an out of the box support > for this use case. > > But yes the format of the JSON is hard to define generally, above RFC was one > of the first search results :-) If there was something that could be done generically at the container level then I'd have no objection but it doesn't look like RFC 7807 is a good fir for that. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RFC7807 ErrorReportValve
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 * The Servlet API mandates that all invocations of HttpServletResponse#setError() must yield in a HTML page and this *cannot* be changed by defult * 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. Before we continue which issue do you want to solve? Tomcat produced errors or by a framework? As for the framework, I would prefer to file an issue with Spring Framework first and see what the devs say because this would solely solve a symptom. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RFC7807 ErrorReportValve
Am 2. Juli 2020 21:45:53 MESZ schrieb Mark Thomas : >On 02/07/2020 20:30, Thomas Meyer wrote: >> Hi, >> >> What are your opinions on providing a RFC7807 based ErrorReportValve >as part of Tomcat default distribution? > >RFC 7807 looks to be application specific so support for that RFC looks >to be better handled at the application level. Mhh, okay, sad to hear. The basic idea was to provide an ErrorReportValve that always responds with an JSON, given the use case that tomcat is sometimes used purely as an HTTP JSON based API server, aka. REST, this Valve would always return an JSON object and not suddenly an HTML page if for any reason something goes horrible wrong. It would be a nice to have for tomcat to provide an out of the box support for this use case. But yes the format of the JSON is hard to define generally, above RFC was one of the first search results :-) Mfg Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: RFC7807 ErrorReportValve
On 02/07/2020 20:30, Thomas Meyer wrote: > Hi, > > What are your opinions on providing a RFC7807 based ErrorReportValve as part > of Tomcat default distribution? RFC 7807 looks to be application specific so support for that RFC looks to be better handled at the application level. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RFC7807 ErrorReportValve
Hi, What are your opinions on providing a RFC7807 based ErrorReportValve as part of Tomcat default distribution? With kind regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
