When in non-blocking mode, calls to SSL.File()->write() may return before data has actually been written to the underlying socket. For applications that close the connection immediately following a write() that completes the data to be sent, this can result in premature closure I/O errors on the receiving side. I first noticed this with some custom SSL code that I'd ported from 7.8, but it also manifests itself when using SSL with the built-in pike HTTP server.

I've solved this problem in my code by waiting for the first write callback after sending the last data before closing the SSL.File object, which seems to work in my application. I've written a patch that does the same for Protocols.HTTP.Server.Request when my_fd is a SSL.File, and it seems to resolve the problem there as well. Does anyone have an objection to this approach? I'm not sure that this approach works for all situations, as I haven't yet looked to see if a write callback can occur while there is still data in the buffer to be written.

Bill