[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCLIENT-1449:
------------------------------------------

    Fix Version/s: 4.4 Alpha1
       Issue Type: Wish  (was: Bug)

> X509HostnameVerifier API is too restrictive
> -------------------------------------------
>
>                 Key: HTTPCLIENT-1449
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1449
>             Project: HttpComponents HttpClient
>          Issue Type: Wish
>    Affects Versions: 4.3.1
>            Reporter: Mikhail Golubev
>            Priority: Minor
>             Fix For: 4.4 Alpha1
>
>
> I want to customize hostname verification process by creating custom 
> X509HostnameVerifier, which first try to use BrowserCompatHostnameVerifier 
> strategy to check hostname and then, if it fails, asks user directly, whether 
> such certificate can be accepted. As I understand, this verifier then can be 
> supplied to e.g. HttpClientBuilder#setHostnameVerifier.
> But how should I achieve this? I can't extend BrowserCompatHostnameVerifier, 
> because all its methods is final or package-private. Extending 
> AbstractVerifier also makes no sense, because its only overridable method  is 
> verify(String, String[], String[]) and it gives me no access to certificate 
> itself, which I need for user dialog. On the other hand, method verify(String 
> host, X509Certificate cert) is the perfect extension point for me, but it's 
> declared final. I really don't like to implement X509HostnameVerifier and 
> then copy half of the AbstractVerifier in it. May be I'm missing some other 
> way to intercept hostname verification?



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to