Hi,
I'm updating some old Jersey JAX-RS code which used Jetty 9 to instead use Jetty 12.1, and one issue I ran into after the update was that sometimes when the Jersey server code returned HTTP 4xx errors it would lead to IOException "broken pipe" errors on the client side.
It looks like perhaps under Jetty 9, the request body would be fully read by the time these JAX-RS filters ran and generated their HTTP 4xx validation errors, while under Jetty 12.1 they might be run and return before the request body has been read. If that happens, the connection can be closed while the client is still trying to write the request body.
In order to avoid these IOExceptions I added an EagerContentHandler to the Jetty handler chain, and the issue seems to have disappeared. The idea is that all request bodies will be again guaranteed to have been read from the network by the time the Jersey code is exercised. However, the JavaDoc for EagerContentHandler talks about objectives in terms of optimization rather than correctness, so I'm not sure if I'm taking the right approach.
Is it expected that JAX-RS applications will need to use an EagerContentHandler to ensure that all JAX-RS handlers and filters are safe to return responses without needing to fully read the request body?
If so, should it just use a RetainedContentLoaderFactory with maxRetainedBytes set to Long.MAX_VALUE in order to mimic the Jetty 9 behavior?
Thanks for any pointers!
Daniel
