-----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
>> <ma...@apache.org>:
>>> 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<String,String>, 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
