[
https://issues.apache.org/jira/browse/HTTPCLIENT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876484#comment-13876484
]
Oleg Kalnichevski commented on HTTPCLIENT-1449:
-----------------------------------------------
Mikhail,
Why do not you want to decorate an existing X509HostnameVerifier instead of
sub-classing it?
Oleg
> X509HostnameVerifier API is too restrictive
> -------------------------------------------
>
> Key: HTTPCLIENT-1449
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1449
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.3.1
> Reporter: Mikhail Golubev
> Priority: Minor
>
> 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]
