Map EPIPE to ERR_CONNECTION_RESET.

Map EPIPE to ERR_CONNECTION_RESET.

R=willchan
BUG=29241
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=33633

[wtc, 2009-12-02 02:50:24]

See the following links on why EPIPE should be mapped to
ERR_CONNECTION_RESET.

1. NSPR maps EPIPE to PR_CONNECT_RESET_ERROR.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/md/unix/un...

2. In the write() man page in Single Unix Specification,
search for [ECONNRESET] and [EPIPE].  Their descriptions
are similar ("not connected" vs. "no longer connected").

http://www.opengroup.org/onlinepubs/9699919799/functions/write.html

[willchan no longer on Chromium, 2009-12-02 19:59:39]

On 2009/12/02 02:50:24, wtc wrote:
> See the following links on why EPIPE should be mapped to
> ERR_CONNECTION_RESET.
> 
> 1. NSPR maps EPIPE to PR_CONNECT_RESET_ERROR.
> 
>
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/md/unix/un...
> 
> 2. In the write() man page in Single Unix Specification,
> search for [ECONNRESET] and [EPIPE].  Their descriptions
> are similar ("not connected" vs. "no longer connected").
> 
> http://www.opengroup.org/onlinepubs/9699919799/functions/write.html

I don't know that I agree with this.  ERR_CONNECTION_RESET as it stands right
now means that the connection was reset, which in TCP translates pretty directly
to a TCP RST.  EPIPE can be issued for a write() where the client has already
called close() or shutdown() on the socket.  EPIPE typically is caused by
programmer error, not by TCP connection resets.  Can you explain further why you
think we should map EPIPE to ERR_CONNECTION_RESET?  I like having
ERR_CONNECTION_RESET distinctly refer to TCP RSTs for TCP sockets.

[wtc, 2009-12-02 23:57:21]

I don't remember why NSPR maps EPIPE to
PR_CONNECT_RESET_ERROR.  I definitely didn't inspect the
TCP packets.  It may have been based on the similarity of
the descriptions of EPIPE and ECONNRESET.

I just wrote some test programs that show a client's write() call
may fail with EPIPE on Mac and Linux if the server has
closed the connection.  I don't have time to inspect the
TCP packets to see if the server sends TCP RST.  Under
the same condition, Windows reports WSAECONNABORTED,
so I propose that we map EPIPE to ERR_CONNECTION_ABORTED.

[wtc, 2009-12-03 00:02:35]

On 2009/12/02 19:59:39, willchan wrote:
> EPIPE typically is caused by
> programmer error, not by TCP connection resets.

This is not true.  EPIPE (or rather SIGPIPE) is caused by
network connection closure by the peer.  Every network client
program must ignore SIGPIPE because the default signal action
for SIGPIPE is to terminate the program.  A client program
with no progammer error will still receive SIGPIPE because of
a server's action.

[willchan no longer on Chromium, 2009-12-03 00:17:51]

On 2009/12/03 00:02:35, wtc wrote:
> On 2009/12/02 19:59:39, willchan wrote:
> > EPIPE typically is caused by
> > programmer error, not by TCP connection resets.
> 
> This is not true.  EPIPE (or rather SIGPIPE) is caused by
> network connection closure by the peer.  Every network client
> program must ignore SIGPIPE because the default signal action
> for SIGPIPE is to terminate the program.  A client program
> with no progammer error will still receive SIGPIPE because of
> a server's action.

I was incredulous so I tested it out, and you're indeed correct.  Even more so,
the server sends a TCP RST in this case (I verified on wireshark).  I also
tested changing the server to write() to the socket after it closed it and that
gave an EBADF, so that was the other situation I was worried about.  I guess I'm
fine with going ahead and using ERR_CONNECTION_RESET here.  Sorry for my
incorrect objection.

LGTM.