On Tue, 5 Feb 2002 [EMAIL PROTECTED] wrote: > Most of the time it happens when something is still in the write > buffer ( i.e. unsent or unread ), and the remote side is closing > the connection.
I'll try again: Assuming CLIENT sending data to SERVER. The exception happens when: - server has received some data from client ( so client believes the data reached the destionation ). The data is in some OS buffer. - server dies or close() the socket, without reading the data from the OS buffer - some OSes have a TCP implementation that does what I believe to be right - send an ABORT ( instead of the regular CLOSE ). - the client will receive the ABORT and throw the exception ( that coresponds to SIGPIPE if the same thing would be done locally ) ( it seems my original mail was not very clear ). My feeling is that we are exaclty in this case - the logic to close the socket is trying to read the remaining data from the available() buffer ( impl. of the fix for extra CRLF bug ), but the impl is likely to fail on a fast OS or on certain threading models where the CLIENT may send aditional data between we read the input buffer and close(). Vincent: is your test servlet reading the body i.e. calls getParameters() if it's a url-encoded body, or read the full stream ? If not, I believe the current behavior is correct and shouldn't be changed - it signals the CLIENT that whatever it posted was not read, and that's a very usefull information we shouldn't hide. If this is not the case, and the servlet has read the body - than it's a serious problem. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
