AccessEvent.getRequestContent() swallows all exceptions thrown by HttpServletRequest.getParameterNames() and HttpServletRequest.getParameter(String) - including ones intended to change how the server responds to the client.
For instance in Jetty 12 using EE10, if you send a request with content type application/x-www-form-urlencoded and more than the default 200,000 byte content length, HttpServletRequest.getParameterNames() throws a org.eclipse.jetty.http.BadMessageException: 400: Unable to parse form content, which ought to be returned to the client as a 400 response. But because AccessEvent.getRequestContent() just swallows it, this is lost.
In addition the use of Throwable.printStackTrace() in a container context is a bit of a disaster - we carefully use LogBack and JSON formatted logging to ensure we can parse log files in DataDog, and this vomits 30+ lines of individual events into DataDog based on untrusted client input we cannot prevent.
AccessEvent.getRequestContent()swallows all exceptions thrown byHttpServletRequest.getParameterNames()andHttpServletRequest.getParameter(String)- including ones intended to change how the server responds to the client.For instance in Jetty 12 using EE10, if you send a request with content type
application/x-www-form-urlencodedand more than the default 200,000 byte content length,HttpServletRequest.getParameterNames()throws aorg.eclipse.jetty.http.BadMessageException: 400: Unable to parse form content, which ought to be returned to the client as a 400 response. But becauseAccessEvent.getRequestContent()just swallows it, this is lost.In addition the use of
Throwable.printStackTrace()in a container context is a bit of a disaster - we carefully use LogBack and JSON formatted logging to ensure we can parse log files in DataDog, and this vomits 30+ lines of individual events into DataDog based on untrusted client input we cannot prevent.