Comment # 45 on bug 1068470 from Marcus H�we

(In reply to Sebastian Parschauer from comment #42)
> headers["Connection"] = "close"
> try:
>     h.request(req.get_method(), selector, req.data, headers)
>     s = h.get_session()
>     if s:
>         self.saved_session = s
>     r = h.getresponse()
> 
Can you try the following? Revert all potential fixes (if applied) that are
mentioned in the github issue and then remove or uncomment

     s = h.get_session()
     if s:
         self.saved_session = s

and check if it still hangs?

My guess is (_not_ verified yet):
- h.get_session() performs a SSL_get_session() (not a SSL_get1_session())
- As you pointed out, we never "close" (== SSL_shutdown(...) == sending a close
  notify alert) the connection (== SSL struct) => the session is considered bad
- When the execution returns from https_open, h is "destroyed"
- Especially, h.sock is "destroyed", which SSL_free()s the SSL struct
  => the session is also SSL_SESSION_free()d (since it is bad)
- If https_open is invoked again, we use the SSL_SESSION_free()d session

Explicitly closing (SSL_shutdown()) is just fixing a symptom (the session
is _not_ considered bad and remains in the session cache (and is not
SSL_SESSION_free()d)). However, it is possible that the session is removed
from the session cache and self.saved_session is dangling again...