ErrorPageErrorHandler does not use the proper attributes for error handling

[jebeaudet]

Jetty version(s)
12.0.14

Jetty Environment
ee10

Java version/vendor
openjdk 21.0.3 2024-04-16 LTS

OS type/version
MacOS

Description
I'm upgrading an app from Jetty 10 to 12 and I'm running into some unexpected errors being mapped by jetty. I'm using the latest Spring Boot 3.3 version with no special custom configuration.

Basically I have a request that is clearly a poor hacking attempt on the path //WEB-INF/classes/META-INF/microprofile-config.properties. This is correctly mapped to a 404 by Jetty, however during error handling, I end up with a blank 500.

Tracing into the code, I see that I end up in the ErrorPageErrorHandler class here : https://github.com/jetty/jetty.project/blob/jetty-12.0.x/jetty-ee10/jetty-ee10-servlet/src/main/java/org/eclipse/jetty/ee10/servlet/ErrorPageErrorHandler.java#L63. This fails because it can't find any Throwable(which is normal AFAICT) but it cannot find a errorStatusCode either so it falls back on the generic error page.

Walking up the stack trace, I see that it's called from the Response interface https://github.com/jetty/jetty.project/blob/jetty-12.0.x/jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/Response.java#L605 with an ErrorHandler.ErrorRequest instance. The ErrorRequest instance has the proper information (the status code + message) but it's under the keys in the ErrorHandler class :

Now, I understand that the servlet + server part has been decoupled completely and that the ErrorPageErrorHandler is correctly looking at the servlet spec keys to find the exception or the status code. However, shouldn't this class also look at the server specific keys as a fallback?

Thanks in advance!

[jebeaudet]

I've made a small repo to reproduce but it's really simple : https://github.com/jebeaudet/jetty-gh-12505

Checkout the code, build and run and just go to http://localhost:8080/WEB-INF/classes/META-INF/microprofile-config.properties and you'll get a 500 instead of what I would expect a 404.

Digging into it some more, I see it's because the WEB-INF and META-INF are protected path! So it really seems like a corner case since a request to /potato will properly end up in 404 with the same ErrorPageErrorHandler, though the statusCode is properly set in those cases.