YDB TLS SNI feature: worth having; or out of scope?

I discovered this issue while updating my TLS support code for VistA that I wrote 2 years ago--I couldn't talk to httpbin.org anymore.

I kept digging around thinking that the problem was in GT.M (I was running GT.M on Cygwin) but in the end, it wasn't. It has to do with whether a server supports SNI; and whether it requests enforcement if you don't supply it one.

This fails:

openssl s_client -connect httpbin.org:443

This succeeded:

openssl s_client -connect httpbin.org:443 -servername httpbin.org

Looking around on the internet, it's easy to do SNI support by just calling SSL_set_tlsext_host_name on the ssl structure. Easy? No... We don't have access to the host name in sr_unix/gtm_tls_impl.c. The socket is already established by this point... which means, practically speaking, that if we want to support this feature, we need to change the WRITE /TLS command syntax to support passing an server name for the SSL_set_tlsext_host_name call.

The other issue is whether this is worth supporting? SNI apparently is common over the internet, esp. if you services like Cloudflare. FYI: somebody else has this issue with httpbin: https://github.com/requests/httpbin/issues/376.

--Sam

PS: Httpbin.org is a web site that lets you run unit tests for web services clients.

PS2: Test case (approximate... it's a pain to compile the plugin on the "supportable" platforms... I am sure you can make it crash properly):

O NIO:(CONNECT="httpbin.org:443:TCP":ATTACH="client":IOERROR="TRAP"):5:"socket"
U NIO
W /TLS("client"); <--error here; in my version I couldn't see what the issue what until I used gdb to walk through the code.