[PYTHON-CRYPTO] Memoryleak in SSL.Connection

[Michael Dunstan]

I have seen the same leak when running ZServerSSL. Had to restart the
server every few days. Until the following change was made for
setblocking:

      def setblocking(self, mode):
          """Set this connection's underlying socket to _mode_."""
          self.socket.setblocking(mode)
          if mode:
-            self.send = self.write = self._write_bio
+            self.send = self.write = Connection._write_bio
_            self.recv = self.read = self._read_bio
+            self.recv = self.read = Connection._read_bio
          else:
-            self.send = self.write = self._write_nbio
+            self.send = self.write = Connection._write_nbio
-            self.recv = self.read = self._read_nbio
+            self.recv = self.read = Connection._read_nbio

This does have different meaning but I don't think that affects the
functionality of the class in this case.

Since applying the patch we have not had any memory problems for some
time. About 8 months now.

Also while debugging the leak found something that may be of interest.
It turns out that IE does not like the headers that zope creates for
304 (Not modified) responses for images. The result is that IE drops
the connection and creates a new one after each 304 it gets for an
image. Each time this happens I see something like the following in
zope event logs:

2003-05-13T10:40:18 INFO(0) ZServer recv: closing channel
<ZServer.HTTPS_Server.zhttps_channel connected 127.0.0.1:1187 at
0x2852014 channel#: 204 requests:> unexpected eof

(At the time that was m2crypto-0.09, Python 2.1.3, Zope 2.6.0.)

Naturally a site that uses images will serve up a lot of 304's and so
you see a lot of these messages for those users using IE. Also you
see a lot more memory usage in Zope without the above fix :-)

It is quite a simple matter to correct the headers used for the image
304's in Zope. There is even an issue in the zope collector about this:
http://collector.zope.org/Zope/544. Looks like this incorrect handling
of the headers in zope is intentional to support caching in some
relic version of apache configured as a proxy server. In our case apache
is clearly not part of the equation (the transaction is encrypted
between
zope and the browser) so it is safe to correct the headers. This is
simply
of applying a patch of the following form to lib/python/OFS/Image.py:

                  if last_mod > 0 and last_mod <= mod_since:
                      # Set header values since apache caching will
return Content-Length
                      # of 0 in response if size is not set here
                      RESPONSE.setHeader('Last-Modified',
rfc1123_date(self._p_mtime))
-                    RESPONSE.setHeader('Content-Type',
self.content_type)
-                    RESPONSE.setHeader('Content-Length', self.size)
                      RESPONSE.setHeader('Accept-Ranges', 'bytes')
                      self.ZCacheable_set(None)
                      RESPONSE.setStatus(304)
                      return ''

(That's bound to have wrapped and looks a little ugly.)

Michael