SSL::sni name not returning value after update to 12.1.3

Hello,

After recently upgrading the lab machine from 12.1.1 to 12.1.3, I have discovered that the following iRule which I have been using to determine if Client SNI and Server SNI match doesn't work anymore:

Version    1.05
Changed    17.01.2017
Summary    This script compares the SNI the client sends to the SNI which the server is using
Summary    If they do not match, the connection is rejected.  In this way a client cannot try to open a https page, for which there is no matching certificate.

when RULE_INIT {
    Set to 1 for writing messages to LTM log file
    set static::debug_log 1
}

when CLIENTSSL_CLIENTHELLO {
    if { [SSL::extensions exists -type 0] } {
        set client_servername [string range [SSL::extensions -type 0] 9 [string length [SSL::extensions -type 0]]]
        set server_servername [SSL::sni name]
        if {$static::debug_log > 0} {log local0. "Client SSL Request Server Name: $client_servername"}
        if {$static::debug_log > 0} {log local0. "Server SSL Profile Name: $server_servername"}
        if {[string tolower $client_servername] ne [string tolower $server_servername]} {
            if {$static::debug_log > 0} {log local0. "Client Request ($client_servername) does not match ($server_servername) - Dropping the Connection"}
            reject
        }
    }
}

The log shows

Rule /Common/Website-SSL-SNI-MatchDomains-iRule : Client Request (www.mydomain.com) does not match () - Dropping the Connection

which leads me to assume that for some reason

SSL::sni name

does not return data after the update.

I used this snipped before because on Port 80 on the same IP I have a virtual server with redirects from a myriad of HTTP-only domains to a handful of SSL-enabled URLs. I have only SSL certificates for these handful of redirection target domains, and with this iRule I was able to reduce calls from all those "HTTPS-Everywhere-Users" who were reporting to me invalid certificates for domains which weren't SSL-enabled - just because their browser forcibly tried to connect to port 443 first.

I hope somebody can tell me what's wrong or show me a different solution.

Regards, Marc