Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Custom bad message error page

You can write your own custom ErrorHandler for these kinds of errors, but it has to be associated with the Server, not a ServletContextHandler. 
Remember, there is no Request object.

Using the Server.setErrorHandler(ErrorHandler) is sufficient to set your custom error handler.

Note that you will need to override and provide your own .badMessageError() implementation.
Keep in mind that it should only produce a body if the status code allows it, and it should only produce 1 ByteBuffer of response body content.
There is absolutely no support for ErrorPage techniques in these kinds of cases.
Do not expect to have headers or anything else in these cases. (a status code only is the majority case).

Also note that this Server level error handler will be called if the incoming legitimate request does not match your servlet context, and that request cannot be dispatched to your context.
(Yes, there are many flavors of HTTP requests that fit this category too)
So it's a good idea to also customize the server level ErrorHandler for these cases too.

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Mon, Aug 7, 2023 at 1:45 PM Joakim Erdfelt <joakim@xxxxxxxxxxx> wrote:
The BadMessageException that occurs during HTTP parsing (before there is a Request object) is handled by ErrorHandler.badMessageError()


That sets the status, and if the status code supports a response body, then it outputs a single line of text that is ...

"<h1>Bad Message " + status + "</h1><pre>reason: " + reason + "</pre>"

(if the status code doesn't support a body, then it's left empty)

There's no exception or anything else Jetty specific that the response produces in this situation.

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Mon, Aug 7, 2023 at 9:50 AM Silvio Bierman via jetty-users <jetty-users@xxxxxxxxxxx> wrote:
Hello Simone,

Thank you for the reply. We do not want to change the compliance, the
error flagging is correct and desired. It is just that some potential
user doing a pen-test on our system is objecting to the messages being
generated. The SNI message contains "Caused by:
org.eclipse.jetty.http.BadMessageException" which is information (Jetty)
we are not allowed to disclose for security reasons. In general the want
the ability to tweak all error messages generated by our application. We
tried to offer that through the custom handler.

There is a Server#setErrorHandler call and I would have expected that
error handler to be used for such low-level errors. But now I understand
that this is not the case I was hoping for some other way to customize
these messages.

Is there anything else I could do to work around this?

Thnaks in advance,

Cheers,

Silvio


On 07-08-2023 16:32, Simone Bordet wrote:
> Hi,
>
> On Mon, Aug 7, 2023 at 12:16 PM Silvio Bierman via jetty-users
> <jetty-users@xxxxxxxxxxx> wrote:
>> Hi,
>>
>> I run embedded Jetty 11.0.13. I have a single servlet instance and call ServletContextHandler#setErrorHandler(customHandler) during initialization. But whenever an invalid URL (like one containing empty segments) the handle method of the custom errorhandler is not called. Instead the message
>>
>> Bad Message 400
>>
>> reason: Ambiguous URI empty segment
>>
>> is generated. Similarly requests with a bad SNI seem to generate a page that does not go through the custom handler.
>>
>> What am I doing wrong? How can I catch these and generate my own error pages?
> Some errors happen very early in the request parsing, so when they
> happen, there is no request, no headers, etc. so we cannot dispatch a
> "request" to a handler (there is no request).
> These are typically requests that are so bad that are typically
> attacks, so you don't want to generate more than a concise 400
> response from the server, as if the request never arrived.
>
> For the particular error "Ambiguous URI empty segment" you can
> configure the HTTP compliance so that the ambiguity is tolerated, and
> the request handled as a normal request.
> See https://eclipse.dev/jetty/documentation/jetty-11/programming-guide/index.html#pg-server-compliance-http.
>

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users

Back to the top