Provider is not consuming the whole input stream request causing the connection abort by Jetty

[molsza]

In case the chunked encoding is used and client has send the whole json in next to last message then provider is returning the parsed object immediately, without waiting for the rest of the message (which is the end of the message). This may cause that response is generated before the last chunk gets to the server, which is treated by the jetty as an erroneous situation and causes the connection abort.

In most cases response is delivered to the client before the connection is closed, but sometimes it happens before that and client reports:

 java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:210)
	at java.net.SocketInputStream.read(SocketInputStream.java:141)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)	

The details of the issue can be found in the jetty tracker: https://github.com/eclipse/jetty.project/issues/3027

[cowtowncoder]

Hmmh. Jackson not reading the whole content, just what it needs, is a feature (as a general note). But I can see how this can be problematic with (potentially) reusable HTTP connections.

Jackson 2.9 finally introduced feature DeserializationFeature.FAIL_ON_TRAILING_TOKENS, enabling of which would force reading of all content, including end-of-input. So enabling that by default would be one option I think. Alternative would be to explicitly constructing JsonParser, and implementing above -- it's easy enough to do, just bind, call nextToken().

But one challenge is whether this is safe to do in 2.9.8 patch or not....