Don't blindly call request.getParameter() without fully (and I do mean
FULLY) understanding the side effects.
A call to request.getParameter() can read the request body content as well.
(per Servlet spec).
A call to request.getParameter() can fail for bad input, bad encoding, bad
expectations, IO exceptions, etc (it's quite a long list of causes).
BadMessageException can occur early during request parsing (for things
related to identifying the context that the request needs to be sent to),
or later during request content access once inside of a request dispatch
(cookies, parts, parameters, locale, charset, content-type, mime-type,
multipart, etc ...)
Since request.getParameter() has no checked exceptions, you are stuck with
RuntimeException.
What would I do?
I wouldn't catch all exceptions in my ErrorPageErrorHandler, but only
specific ones that I care about presenting to users.
I wouldn't catch (for example) anything in the Throwable or Error
categories, only Exception.
Joakim Erdfelt / joa...@webtide.com
On Mon, May 22, 2023 at 8:30 AM John English <john.fore...@gmail.com> wrote:
> I have a catch-all exception handler which sends me an email for
> unhandled exceptions in case it's due to a bug in the code. Recently I
> had a flurry of emails because of a URL where someone had entered
> "/foo?bar=%" ("%" being a typo for "5" in this case):
>
> org.eclipse.jetty.http.BadMessageException: 400: Unable to parse URI query
> at org.eclipse.jetty.server.Request.getParameters(Request.java:454)
> at org.eclipse.jetty.server.Request.getParameter(Request.java:1075)
> at ...
>
> Since this is not due to something in the code, there's nothing I can do
> about it. If I try "/foo%", I get a 400 response before my code sees it,
> which is OK.
>
> I'd like to ignore the exception, but I'd prefer not to have to make the
> code dependent on a class which is Jetty-specific. However, BME is
> derived from RuntimeException, so I can't just ignore the base class
> either.
>
> Plan B: Call request.getParameter() inside a try block at the start of
> request processing, and return a 400 response (as this exception seems
> to be trying to do) if an exception is thrown. But are there any other
> gotchas like this that I need to be aware of here? What other exceptions
> might it throw, and under what circumstances?
>
> Any ideas? What would *you* do in this situation?
>
> --
> John English
> _______________________________________________
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
