Daniel,
I can't reproduce your issue. I get the 408 with or without the 3 lines that write the body?!?!?
However, I would say that expecting to always get a response from such an request in a repeatable fashion is not really viable. While we'd like to make jetty as consistent as possible, who knows what firewalls, proxies, and other intermediaries may do on long pauses. Chances are that something else might close the connection first. So if you have any control over your client, then I suggest making it robust against closed connections for stalled requests.
It may be that in your environment the body is not available to be readily consumed after the error response, so jetty is giving up in its consumeAll method and just closing the connection. It does this because it can be a DOS vector if jetty continues to read, buffer and parse input long after an error response has been sent.
Jetty is certainly never going to wait for a connection which has already exceeded an idle timeout to send content. It does try to consumeAll, but if there is a chance of blocking it gives up and closes the connection. Somehow in your environment, the hard close of the connection is overtaking the 408 response that is already sent and this is being caused by the write of the body to the closed connection. The 408 might even be lost in your client. Getting a TCP/IP trace of the conversations with and without the body write would be helpful. If you can get them, please attach them to the issue.
cheers
regards