By oleksiys on Jun 13, 2007
Recently I was investigating Grizzly related bug, which appeared when Grizzly tried to redirect (HTTP response code 302) Java HTTPS client. And the bug appeared only in situations, when client tried to send some payload data to server, not just HTTP headers.
Finally I realize, that it has nothing to do neither with Grizzly nor HTTPS/SSL. Following scenario fully reproduces the problem with clear Sockets:
1) Client -> Server: client sends request chunk#1
2) Server -> Client: server reads chunk#1, processes, writes response
3) Server closes connection
4) Client -> Server: client sends request chunk#2
5) Client tries to read server response: "java.net.SocketException: Software caused connection abort: recv failed"
As the result client will not be able to read any byte from server's response!
What is interesting on step (4) we don't see any exception, but this step (sending data over connection, which is closed by peer) is the reason of the exception we're getting on (5). Removing step (4) from our scenario, or putting it before step (3) - makes everything work.
Actual exception looks strange for me, as it is thrown not from the place, which causes the problem.