Hello,
I am facing a very weird issue. I have a project that uses HttpClient4 to
make a simple GET request to Apache Tomcat. It was all working fine.
Now I need to upgrade to HttpClient5. I managed to upgrade very easy - just
a small package renames. However when I make the same request the tomca
On Thu, Aug 10, 2023 at 9:14 PM Petar Tahchiev wrote:
> I found this gist which tells how to provide a SNI:
>
> https://gist.github.com/jkuipers/e0b35c21c466a9b4d88a
>
> but it is for HttpClient4 and I am unable to migrate the code to
> HttpClient5.
>From looking at the gist, all that it does is
Hmm,
I tried now setting the Host header:
httpGet.setHeader("Host", "localhost");
yet tomcat still logs null for SNI
На чт, 10.08.2023 г. в 22:21 ч. Jochen Wiedmann
написа:
> On Thu, Aug 10, 2023 at 9:14 PM Petar Tahchiev
> wrote:
>
> > I found this gist which tells how to provide a SNI:
>
Hi, Petar,
looking through
https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
I get the impression, that SNI is a server-side issue. So, the actual
problem may be on the server side, rather than the client side. To
begin with: Do you really need two different SSL certificates within
one
Hi Jochen,
I don't have 2 different SSL certificates.
I have no idea what SNI is but that seems to be the only difference in the
log from curl and httpclient5.
This is from curl:
--
On Thu, 2023-08-10 at 22:40 +0300, Petar Tahchiev wrote:
> Hmm,
>
> I tried now setting the Host header:
>
>
> httpGet.setHeader("Host", "localhost");
>
>
This is wrong. You should not be doing that. You should let HttpClient
generate the Host header when appropriate. HttpClient will also
aut
Hello,
so I'm getting closer. Because I was
using PoolingAsyncClientConnectionManager I decided to replace it
with PoolingHttpClientConnectionManager and it worked. So the problem is
not in the SNI but in the PoolingAsyncClientConnectionManager. I am
following this guide exactly:
https://hc.apache
On Fri, 2023-08-11 at 13:08 +0300, Petar Tahchiev wrote:
> Hello,
>
> so I'm getting closer. Because I was
> using PoolingAsyncClientConnectionManager I decided to replace it
> with PoolingHttpClientConnectionManager and it worked. So the problem
> is
> not in the SNI but in the PoolingAsyncClient
Hi Oleg,
sorry but I am new with this. "This, of course, is not going to work" -
what is not going to work and why not?
"You need to pass HttpHost with the IP address of the physical endpoint.
This cannot be done with Simple* messages. They are simple for a reason." -
I don't understand this. Wher
Hi Peter,
If we can improve our migration guide, then I'm all for it. I'm not sure
how to condense this into a simple before and after example though.
Gary
On Fri, Aug 11, 2023, 8:01 AM Petar Tahchiev wrote:
> Hi Oleg,
> sorry but I am new with this. "This, of course, is not going to work" -
>
On 8/10/23 14:03, Petar Tahchiev wrote:
Hi Jochen,
I don't have 2 different SSL certificates.
I have no idea what SNI is but that seems to be the only difference in the
log from curl and httpclient5.
https://en.wikipedia.org/wiki/Server_Name_Indication
Basically it's a feature of TLS that all
I see no evidence of SNI not working:
try (final CloseableHttpAsyncClient client = HttpAsyncClients.custom()
.build()) {
client.start();
final HttpHost endpoint = new HttpHost("https",
InetAddress.getByName("www.google.com"), "www.google.ch", 443);
final HttpClientContext cl
Yes,
like I already mentioned it is not a SNI problem.
Because I was using PoolingAsyncClientConnectionManager I decided to
replace it with PoolingHttpClientConnectionManager and it worked. So the
problem is not in the SNI but in the PoolingAsyncClientConnectionManager. I
am following this guide e
On Sat, 2023-08-12 at 12:27 +0300, Petar Tahchiev wrote:
> Yes,
> like I already mentioned it is not a SNI problem.
>
> Because I was using PoolingAsyncClientConnectionManager I decided to
> replace it with PoolingHttpClientConnectionManager and it worked. So
> the
> problem is not in the SNI but
14 matches
Mail list logo