Looks good!
I'll let you know if I have any issues, but don't expect any.
Dan
On Mon, Feb 2, 2015 at 6:23 PM, Oleksiy Stashok
<oleksiy.stashok_at_oracle.com> wrote:
> Hi Dan,
>
> On 01.02.15 11:52, Daniel Feist wrote:
>>
>> Does JDK6 even support SNI? I had understood it didn't but pherhaps
>> it is just SNI via new Socket(hostname) that it's not supported in
>> Java6. Do yo know?
>
> No, it's not supported in JDK6.
>
> Instead of using reflection I made this change [1].
> Now on Grizzly requires JDK 1.7 for compilation, but it still supports JDK
> 1.6 at runtime.
> I doubt many people use 1.6 to compile Grizzly, so IMO it should be safe.
>
> WDYT?
>
> WBR,
> Alexey.
>
> [1]
> https://java.net/projects/grizzly/sources/git/revision/6a0b99359611d94b7a263a66cdd02a4d0ec0d9ba
>
>> Either way I'd agree would need to use reflection to call
>> getHostNameString() if JDK needs to be supported.
>>
>> What I'm less sure about is what the best approach with JDK6 is
>> (assuming it's supported):
>> i) SSLContext.createSSLEngine() -> no SNI
>> ii) getHostString() -> potentially unknown latency of host resolution
>> being introduced even when user may not care about SNI
>> iii) Use some other mechanism to determine if the Adress was created
>> with ip or hostname and only use getHost() in the latter case?
>>
>> Dan
>>
>> On Fri, Jan 30, 2015 at 11:10 AM, Oleksiy Stashok
>> <oleksiy.stashok_at_oracle.com> wrote:
>>>
>>> On 29.01.15 23:35, Daniel Feist wrote:
>>>>
>>>> What I don't like about this approach is that
>>>> java.net.InetSocketAddress#getHostName can provoke a reverse lookup
>>>> :-(
>>>
>>> Agree, in JDK7 there's getHostNameString(), which is probably what we
>>> need,
>>> but we have to be JDK6 compatible.
>>>
>>>> We really need to be using the orignal host/ip such that if an ip was
>>>> specified i) no SNI is used ii) no reverse lookups are performend.
>>>
>>> Looks like the only option for now (till we drop JDK6 support) is to use
>>> reflections and call getHostNameString();
>>>
>>> WDYT?
>>>
>>> WBR,
>>> Alexey.
>>>
>>>
>>>
>>> On Tue, Jan 27, 2015 at 11:15 PM, Oleksiy Stashok
>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>
>>>>> Makes sense, just updated SSLFilter on 2.3.x branch.
>>>>> Can you pls. check if it works for you?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>>
>>>>>
>>>>> On 27.01.15 06:18, Daniel Feist wrote:
>>>>>>
>>>>>> In grizzly or AHC?
>>>>>>
>>>>>> In my mind there is no reason why the Grizzly SSLFilter shoudn't use
>>>>>> SSLContext.createSSLEngine(host, port). This would mean i) no changes
>>>>>> to AHC ii) Grizzly will support client SNI by default which I don't
>>>>>> see an issue with.
>>>>>>
>>>>>> BTW, I agree using SSLContext.createSSLEngine(host, port) is most
>>>>>> correct/direct approach. What i did creating socket with hostname is
>>>>>> kinda indirect, I used it primrily as a way of getting httpClient 3.1
>>>>>> to do SNI without needs to modify it.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>> On Mon, Jan 26, 2015 at 11:48 AM, Oleksiy Stashok
>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>
>>>>>>> I'll take a look at AHC and make it use
>>>>>>> SSLContext.createSSLEngine(host,
>>>>>>> port).
>>>>>>> Can I ask you to file a bug for it?
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> WBR,
>>>>>>> Alexey.
>>>>>>>
>>>>>>>
>>>>>>> On 23.01.15 13:05, Daniel Feist wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> AHC uses the SSLFilter and doesn't use
>>>>>>>> SSLContext.createSSLEngine(host, port) anywhere and so obviously
>>>>>>>> doesn't work. If SSLFilter is switched out for SNIFilter than
>>>>>>>> things
>>>>>>>> work. But i beleive there are three potential options and I'm not
>>>>>>>> sure which is best
>>>>>>>>
>>>>>>>> 1) Switch out us the implementation SwitchingSSLFilter extends from
>>>>>>>> SSLFilter to SNIFilter.
>>>>>>>> 2) Use SSLContext.createSSLEngine(host, port) in AHC
>>>>>>>> 3) Simply create socket with String host name and not InetAddress.
>>>>>>>>
>>>>>>>> I just added support for use of HttpClient31 via doing 3) and it
>>>>>>>> works, java7+ handles the rest.
>>>>>>>>
>>>>>>>> Fix:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/mulesoft/mule/commit/416f594ae8d99eb1f8304f0bb549f372825e241c
>>>>>>>>
>>>>>>>> Context regarding this approach for enabling SNI:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/HTTPCLIENT-1119?focusedCommentId=13769887&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13769887
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>> On Fri, Jan 23, 2015 at 8:49 PM, Oleksiy Stashok
>>>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Exactly, it's enough to create SSLEngine using
>>>>>>>>> SSLContext.createSSLEngine(host, port) and pass the host name.
>>>>>>>>> I don't remember what we do in ahc, so will appreciate if you can
>>>>>>>>> doublecheck that.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>> WBR,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 23.01.15 12:21, Daniel Feist wrote:
>>>>>>>>>>
>>>>>>>>>> Simply replace SSLFilter with SNIFilter in the provider
>>>>>>>>>> implementation.
>>>>>>>>>>
>>>>>>>>>> But TBH looking at SNI more closely I dont think this approach
>>>>>>>>>> with
>>>>>>>>>> SNIFilter is even required for outbound http. Ensuring the socket
>>>>>>>>>> is
>>>>>>>>>> created with the hostname and not ip is enough. So hold off for a
>>>>>>>>>> while and I'll come back to you..
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 23, 2015 at 7:42 PM, Oleksiy Stashok
>>>>>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Pls. share the "hack" - I can commit it to ahc.
>>>>>>>>>>>
>>>>>>>>>>> WBR,
>>>>>>>>>>> Alexey.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 23.01.15 04:35, Daniel Feist wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Fanstastic, works a treat. Just had to hack AHC a bit to use it
>>>>>>>>>>>> :-(
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jan 23, 2015 at 1:14 AM, Oleksiy Stashok
>>>>>>>>>>>> <oleksiy.stashok_at_oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Dan,
>>>>>>>>>>>>>
>>>>>>>>>>>>> yes, SNIFilter is compatible with SSLFilter, it just extends it
>>>>>>>>>>>>> with
>>>>>>>>>>>>> SNI
>>>>>>>>>>>>> support.
>>>>>>>>>>>>>
>>>>>>>>>>>>> WBR,
>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 22.01.15 16:44, Daniel Feist wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just a very quick question. Is the use of SNIFilter instead
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> SSLFilter fully compatible with the SSLFilter.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> i.e Can i always use the SNIFilter for SSL and have SNI
>>>>>>>>>>>>>> supported,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> also not have to worry if SNI isn't supported/required by the
>>>>>>>>>>>>>> target
>>>>>>>>>>>>>> server? It looks like it is, but this isn't clear from
>>>>>>>>>>>>>> javadoc,
>>>>>>>>>>>>>> so
>>>>>>>>>>>>>> wanted to check.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks!
>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>