Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Question about HTTPS bad request error message

One word of warning.

Error 400 is a bit unique and special in that many kinds of error 400 happen very early in the processing of a potential incoming request.
Many times the error 400 occurs before a context is known and as a result the error is served directly from the server, and not a context that would have the ErrorPageErrorHandler API.

If the concern is that the error page has a stacktrace, then you can turn that off in the ErrorHandler.setShowStacks(false).
A typical setup on a server is that the server itself has a generic ErrorHandler, and each context (webapp) has it's own ErrorPageErrorHandler which has mappings for exceptions or status codes to resources (dynamic or static) that handle the error.

Joakim Erdfelt / joakim@xxxxxxxxxxx

On Mon, Jul 22, 2019 at 6:58 AM Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

On Mon, Jul 22, 2019 at 12:25 PM Silvio Bierman
<sbierman@xxxxxxxxxxxxxxxxxx> wrote:
> Hello all,
> We run an application that embeds Jetty 9.4.19. Upon receiving a
> malformed request where the Host header has been deliberately set to
> (and therefore does not match the request URL) our server
> responds with:
> Problem accessing /. Reason:
> Host does not match SNI
> Caused by:
> <stacktrace>
> During a pen-test that was done by one of our customers this was deemed
> too much internal information. What is the most easy way to configure
> the error info that we return upon such requests?

Custom error pages, by using the ErrorPageErrorHandler API, see e.g.

Simone Bordet
Developer advice, training, services and support
from the Jetty & CometD experts.
jetty-users mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top