asyncore.dispatcher.send doesn't handle ECONNRESET,
whereas recv correctly does.

When such an error occurs, Zope displays for instance:
ERROR(200) ZServer uncaptured python exception, closing
channel <ZServer.HTTPServer.zhttp_channel connected
x.x.x.x:33054 at 0x4608ac2c channel#: 50679 requests:>
(socket.error:(104, 'Connection reset by peer')
[/usr/local/lib/python2.3/asynchat.py|initiate_send|218]
[/usr/local/zope/2.7.2/lib/python/ZServer/medusa/http_server.py|send|417]
[/usr/local/lib/python2.3/asyncore.py|send|337])

zhttp_channel is just a subclass of http_channel.
The exception is raised by asyncore itself when it
receives the unhandled error.

A proposed fix would be to do the same kind of handling
than is done in recv, but I don't know enough about
asyncore to know if it's correct

It would seem to me that a connection where sending raises ECONNRESET, ENOTCONN, or ESHUTDOWN, should be closed, as is the case in recv.

However, generally send is usually called before recv, so if we close the connection in send, then recv won't get called.  In basically all cases, we want recv() to be called so that we get data from the buffers if possible.  Usually if there is data in the buffers, an exception won't be raised, so we wouldn't close the connection until the next pass.

If we make a change at all, I would change send() to:

    def send(self, data):
        try:
            result = self.socket.send(data)
            return result
        except socket.error, why:
            if why[0] == EWOULDBLOCK:
                return 0
            elif why[0] in [ECONNRESET, ENOTCONN, ESHUTDOWN]:
                return 0
            else:
                raise

I have not yet tested the behavior in Python 2.5 yet, as the test cases for Python 2.5 asyncore are basically nonexistent.  If we added portions of the test cases provided in patch #909005, we could more easily test these kinds of things.

We are actually closing the socket before returning in the latest
version of asyncore.  Closing as fixed.