tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: RFC7807 ErrorReportValve
Date Tue, 07 Jul 2020 14:02:00 GMT
Hash: SHA256


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<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
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message