Sorry I wasn't able to get back to you sooner.

If having a trailing dot in the cert is an RFC violation, then case 2 can be left alone.

As for case 3, we can be more explicit:  if hostname ends in a dot AND cert does not end in a dot, strip dot from hostname.  This seems to be what Ryan was saying Chrome does.

I did a test using s_client in openssl.  Testing all 4 cases in the truth table returned 200s.  

$ openssl s_client -connect www.google.com.:443
...
# Enter next two lines and press return twice
HEAD / HTTP/1.0
Host: www.google.com.

# Returns 200
HTTP/1.0 200 OK
Date: Sat, 11 Nov 2017 21:20:44 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
...

So it would appear openssl against Google handles dots ok, but I could be wrong.  I don't know what server software they are running.

As for testing other server ssl implementations what are you looking for? 

I found a small C openssl client implementation.

https://ubuntuforums.org/showthread.php?t=2217101&p=12989750#post12989750

Compiling that code with some minor tweaks against openssl and testing it with different hostnames and Host headers (dot and no dot), the ssl connection was established and data read.  Invalid constructs led to errors.

Yes, you could move the logic to urllib, but I'm not sure it's practical as many folks just expect the ssl lib to handle the nuances.  If users have to handle it themselves or include urllib, it seems like an extra lift.

I appreciate you taking the time to consider the issue.