I think I hit this exact problem when using apache as reverse proxy in front of jetty. As java documents [*] state, socket.close() means that the application is done with the socket, both input and output. As on tcp-level, the only way for system to close both input and output streams of a tcp connection, is to send a RST packet. And this is what java implementations do.They first send FIN/ACK for the output stream, followed by RST to close the input stream as well.
This is not what apache mod_proxy expects. We have a case where client does a big http POST, say 2 megs. Apache proxy begins to transmit this request to the jetty. After reading a few kBs, jetty notices that the request needs to be authenticated. At this point jetty responds with HTTP 401, and closes the connection (socket.close() --> FIN + RST). Apache mod_proxy receives response and the FIN, immediately followed by RST-message.
Now, what should mod_proxy do? TCP specification says that after RST all communication should immediately stop. Mod_proxy still has lots of request data to send. Some data hes been received, but so has RST. At this point, mod_proxy decides that the connection is broken, and result code HTTP 502 is returned to the client.
I think this is a little gray area regarding the functionality of the HTTP protocol. Can server break the connection before the whole request is sent, and assume the client will handle the already-sent response? And of course it is pretty silly to send a 2 meg request twice, just to authenticate the user. All I know is, that currently this behaviour breaks proxied connections. If I could decide, I had this fixed in mod_proxy, as it would not break existing applications. However, jetty could provide an alternative (cleaner?) way of handling http-requests (consume all the request data before closing connection).