Spring REST API (with Jackson) running on EC2 Linux machine with java 1.8.0_65, over a jetty-distribution-9.3.0.v20150612 server.
Most API calls work well, but sometimes my clients (mobile app / curl) receive a bad response - curl: (18) transfer closed with outstanding read data remaining. It reproduced on local and remote Jetty machines, with and without compression and SSL.
I've captured the communication using Wireshark, it looks like while sending chunks of 1414 bytes, suddenly (before whole JSON content was sent) there's a smaller chunk with a FIN flag set.
What can cause the chunk stream to end prematurely?
Update
After a lot of divide and conquer, I've found an emoji character in the response object that may cause the issue.
But what's strange is that changing any data in that string, without removing the character will cause this to work. As if it's not the character itself, but its position in the string.
Currently the response object is automatically serialized into JSON through spring-webmvc:4.1.7, when this object is manually serialized and sent it works. The data member holding that emoji is annotated with @JsonRawValue, its value is already serialized to JSON.
Emoji characters weren't escaped in the JSON response.
Since the data member containing this Emoji wan't handled by Spring MVC serializer, it was sent as a raw string in a JSON object, it was escaped manually using a method that didn't handle a whole set of unicode characters.
Replacing the manual escaping method with Apache's StringEscapeUtils.escapeJson(..) provided at the commons-lang3:3.3.2 library solved the issue.