The HTTPS server that is called by the snip.https_server application dies with repetitive client requests.
If you simply build the default application (SDK 6.4), then run it, you will see that the server permanently fails if you send closely-spaced client requests. You can do this by simply making a bookmark to the device URL (e.g., https://192.168.2.157/apps/https_server/https_server_top.html), then clicking on the link in quick succession (e.g., 2 to 5 times/sec). After a few seconds of clicking, the server dies (Firefox indicates no further pages are served).
Note that the function http_server_deferred_connect_callback() still appears to be called, but nothing happens after it is called.
By the way, it is much easier to reproduce if you make a page that takes a little longer to render. For example, if you modify the file resources/https/server/https_server_top.html by adding a couple of thousand lines of print (to emulate a page that is rendered dynamically by the CPU), then it is easy to reproduce.
Update: I have been pounding the webserver for a few days and it seems to be stable. No hanging. I suspect you were correct in saying the system resources were being exhausted. Perhaps the malloc's built-up quickly until there was no memory left. By adding delays as indicated, the peak malloc's likely no longer reach the point of exhaustion. So, case closed. Thanks for your help on this.