Closed keedi closed 10 years ago
While it would not be too hard to let the user override the detected features of openssl I don't think, that it would be a good idea. Because:
In my opinion this leaves only the case, where the OS has fixes, but does not ship with Perl or with IO::Socket::SSL. In this case the user either is expert enough to know, that the OS openssl has fixes for SNI - in think the user should be able to adapt IO::Socket::SSL too. Or the user has no such expert knowledge - in this case he probably does not care at all.
In any case I think the correct setting should be done for all applications in IO::Socket::SSL and not be necessary to do in each application. So if you have a reliable way to detect openssl which has these fixes backported I could incorporate it into IO::Socket::SSL.
Hello,
I already read RT #83289 and SNI support section of IO::Socket::SSL.
But sometimes if user could know exactly his ssl could support SNI or not, although its version is 0.9.8.x. Current code of IO::Socket::SSL looks like:
IO::Socket::SSL code, Line 40
So, someone who are using ssl 0.9.8 which is backported SNI could not use SNI option. I hope to check using
can_client_sni()
rather than$can_client_sni
lexical variable. Because If user risk the ssl 0.9.8 version then he can overridecan_client_sni()
then he could use SNI features of his SSL.How about change the code like:
If this feature request is not Please ignore and close this feature request if it is inappropriate. :-)
Thanks!