Disable HTTP2 profile from iRule?

Hi! We will implement HTTP2 since it's supported in version 12. There is one iRule assigned to VIP that requires SSL renegotiation. Renegotiation conflicts with HTTP2 and gives SPDY protocol error. This iRule asks for a client certificate from card reader for a specific URL and country. It's easy to select another SSL profile with renegotiation enabled for this specific country, but it would be better to use another SSL profile for this specific URI only. HTTP URI is not allowed within CLIENT_ACCEPTED, but we can live with disabling HTTP2 for a country if there is no way to accomplish this.

The most important is to figure out how to disable HTTP2 profile on the VIP for this URL or country. I have not yet found a solution for this. WAM::disable is not working.

Any help is highly appreciated because this is a blocker now for enabling HTTP2.

iRule:

 Initialize the variables on new client tcp session.
when CLIENT_ACCEPTED {
    set collecting 0
    set renegtried 0
 Find out country tag
    set CountryID "[whereis [IP::client_addr] country]"
 Use SSL profile with renegotiation enabled  
    if {$CountryID eq "EE"} {
    SSL::profile with_renegitiation_enabled   
    }

}

 Runs for each new http request
when HTTP_REQUEST {
     /player/identification/eid/start triggers client cert renegotiation
    if { $renegtried == 0 and [SSL::cert count] == 0 and (([HTTP::uri] starts_with "/player/identification/eid/start") || ([HTTP::uri] starts_with "/player/authentication/authentication/loginEid")) } {
     Collecting means buffering the request. The collection goes on
     until SSL::renegotiate occurs, which happens after the HTTP
     request has been received. The maximum data buffered by collect
     is 1-4 MB.
    WAM::disable
    HTTP::collect
        set collecting 1
        SSL::cert mode request
        SSL::renegotiate
       }
}

 After a handshake, we log that we have tried it. This is to prevent
 constant attempts to renegotiate the SSL session. I'm not sure of this
 feature; this may in fact be a mistake, but we can change it at any time.
 It is transparent if we do: the connections only work slower. It would,
 however, make BigIP detect inserted smartcards immediately. Right answer
 depends on the way the feature is used by applications.
when CLIENTSSL_HANDSHAKE {
    if { $collecting == 1 } {
        set renegtried 1
     Release allows the request processing to occur normally from this
     point forwards. The next event to fire is HTTP_REQUEST_SEND.
    HTTP::release
    }
}

 Inject headers based on earlier renegotiations, if any.
when HTTP_REQUEST_SEND {
    clientside {
     Security: reject any user-submitted headers by our magic names.
    HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE"
    HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED"
     if certificate is available, send it. Otherwise, send a header
     indicating a failure, if we have already attempted a renegotiate.
    if { [SSL::cert count] > 0 } {
        log local0. "Client Certificate: [X509::subject [SSL::cert 0]]"

        HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE" [X509::whole [SSL::cert 0]]
    } elseif { $renegtried == 1 } {
         This header has some debug value: if the FAILED header is not
         present, BigIP is probably not configured to do client certs
         at all.
        HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" "true"
    }
    }
}