-----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