[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446909#comment-17446909
]
Tim te Beek commented on HTTPCLIENT-2187:
-
Was able to find this place in the codebase where a SSLConnectionSocketFactory
is created; might that be related?
[https://github.com/wiremock/wiremock/blob/master/src/main/java/com/github/tomakehurst/wiremock/http/HttpClientFactory.java#L110]
I'm a bit new to the WireMock project specifics, as well as Apache HttpClient,
specially where it concerns the proxy/https handling.
So sorry if details are only trickling in. Trying to brush up where I can but
it's taking some time.
> Classic proxy handling for HTTPS seems broken as of 5.1.1+
> --
>
> Key: HTTPCLIENT-2187
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2187
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.1, 5.1.2, 5.2-alpha1
>Reporter: Tim te Beek
>Priority: Major
>
> Classic proxy handling for HTTPS seems to have broken as of 5.1.1+, as seen
> here: [https://github.com/wiremock/wiremock/pull/1698]
> To give just one sample, we now see a failure stacktrace such as this:
> {{java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:637)}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.upgrade(PoolingHttpClientConnectionManager.java:454)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.upgradeTls(InternalExecRuntime.java:190)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:172)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:197)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:89)}}
> {{ at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.getContent(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:67)}}
> {{ at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.configures_jvm_proxy_and_enables_browser_proxying_https(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:63)}}
> That test basically calls this class to set the System proxy properties:
> [https://github.com/wiremock/wiremock/blob/master/src/main/java/com/github/tomakehurst/wiremock/http/JvmProxyConfigurer.java#L48]
> For HTTP that still works fine, for HTTPS it now fails.
>
> There were some recent changes in 5.1.1 related to proxy handling & keep
> alive for async:
> [https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-2177]
> [https://github.com/apache/httpcomponents-client/compare/50f93ec18be8d6f49138825356051c4c0b60dce4...90f69c87b27b721ea8f0e23bdb4baf92bd7cde06]
> However, we're using classic still, and seeing the error above, so not sure
> it's related.
> Could anyone look into why we are now having these issues with only a patch
> version bump?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446885#comment-17446885
]
Oleg Kalnichevski commented on HTTPCLIENT-2187:
---
[~timtebeek] Request execution via HTTPS over a HTTP/1.1 works just fine for
me. It looks like in your case something breaks in the TLS layer but given no
exception gets logged I cannot say what exactly.
Are you using a custom {{ConnectionSocketFactory}} by any chance?
Oleg
{noformat}
Executing request GET /get via http://127.0.0.1:
2021-11-20 23:17:17,642 DEBUG ex-01 preparing request execution
2021-11-20 23:17:17,649 DEBUG ex-01 Cookie spec selected: strict
2021-11-20 23:17:17,652 DEBUG ex-01 Auth cache not set in the context
2021-11-20 23:17:17,652 DEBUG ex-01 target auth state: UNCHALLENGED
2021-11-20 23:17:17,653 DEBUG ex-01 acquiring connection with route
{tls}->http://127.0.0.1:->https://httpbin.org:443
2021-11-20 23:17:17,653 DEBUG ex-01 acquiring endpoint (3 MINUTES)
2021-11-20 23:17:17,654 DEBUG ex-01 endpoint lease request (3 MINUTES)
[route: {tls}->http://127.0.0.1:->https://httpbin.org:443][total available:
0; route allocated: 0 of 5; total allocated: 0 of 25]
2021-11-20 23:17:17,658 DEBUG ex-01 endpoint leased [route:
{tls}->http://127.0.0.1:->https://httpbin.org:443][total available: 0;
route allocated: 1 of 5; total allocated: 1 of 25]
2021-11-20 23:17:17,668 DEBUG ex-01 acquired ep-00
2021-11-20 23:17:17,668 DEBUG ex-01 acquired endpoint ep-00
2021-11-20 23:17:17,669 DEBUG ex-01 opening connection
{tls}->http://127.0.0.1:->https://httpbin.org:443
2021-11-20 23:17:17,669 DEBUG ep-00 connecting endpoint (3 MINUTES)
2021-11-20 23:17:17,670 DEBUG ep-00 connecting endpoint to
http://127.0.0.1: (3 MINUTES)
2021-11-20 23:17:17,671 DEBUG http-outgoing-0 connecting to /127.0.0.1:
2021-11-20 23:17:17,672 DEBUG http-outgoing-0 connection established
127.0.0.1:55912<->127.0.0.1:
2021-11-20 23:17:17,672 DEBUG ep-00 connected http-outgoing-0
2021-11-20 23:17:17,672 DEBUG ep-00 endpoint connected
2021-11-20 23:17:17,673 DEBUG ep-00 start execution ex-01
2021-11-20 23:17:17,673 DEBUG ep-00 executing exchange ex-01
over http-outgoing-0
2021-11-20 23:17:17,674 DEBUG http-outgoing-0 >> CONNECT httpbin.org:443
HTTP/1.1
2021-11-20 23:17:17,674 DEBUG http-outgoing-0 >> Host: httpbin.org:443
2021-11-20 23:17:17,674 DEBUG http-outgoing-0 >> User-Agent:
Apache-HttpClient/5.1.3-SNAPSHOT (Java/1.8.0_282)
2021-11-20 23:17:17,879 DEBUG http-outgoing-0 << HTTP/1.1 200 Connection
established
2021-11-20 23:17:17,879 DEBUG ex-01 connection kept alive
2021-11-20 23:17:17,881 DEBUG ex-01 tunnel to target created.
2021-11-20 23:17:17,881 DEBUG ep-00 upgrading endpoint
2021-11-20 23:17:17,919 DEBUG Enabled protocols: [TLSv1.2]
2021-11-20 23:17:17,920 DEBUG Enabled cipher suites:
[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
2021-11-20 23:17:17,921 DEBUG Starting handshake
2021-11-20 23:17:18,500 DEBUG Secure session established
2021-11-20 23:17:18,501 DEBUG negotiated protocol: TLSv1.2
2021-11-20 23:17:18,501 DEBUG negotiated cipher suite:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2021-11-20 23:17:18,502
[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446884#comment-17446884
]
Oleg Kalnichevski commented on HTTPCLIENT-2187:
---
[~timtebeek] I see neither an exception nor anything wrong in the log.
Oleg
> Classic proxy handling for HTTPS seems broken as of 5.1.1+
> --
>
> Key: HTTPCLIENT-2187
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2187
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.1, 5.1.2, 5.2-alpha1
>Reporter: Tim te Beek
>Priority: Major
>
> Classic proxy handling for HTTPS seems to have broken as of 5.1.1+, as seen
> here: [https://github.com/wiremock/wiremock/pull/1698]
> To give just one sample, we now see a failure stacktrace such as this:
> {{java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:637)}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.upgrade(PoolingHttpClientConnectionManager.java:454)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.upgradeTls(InternalExecRuntime.java:190)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:172)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:197)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:89)}}
> {{ at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.getContent(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:67)}}
> {{ at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.configures_jvm_proxy_and_enables_browser_proxying_https(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:63)}}
> That test basically calls this class to set the System proxy properties:
> [https://github.com/wiremock/wiremock/blob/master/src/main/java/com/github/tomakehurst/wiremock/http/JvmProxyConfigurer.java#L48]
> For HTTP that still works fine, for HTTPS it now fails.
>
> There were some recent changes in 5.1.1 related to proxy handling & keep
> alive for async:
> [https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-2177]
> [https://github.com/apache/httpcomponents-client/compare/50f93ec18be8d6f49138825356051c4c0b60dce4...90f69c87b27b721ea8f0e23bdb4baf92bd7cde06]
> However, we're using classic still, and seeing the error above, so not sure
> it's related.
> Could anyone look into why we are now having these issues with only a patch
> version bump?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446880#comment-17446880
]
Tim te Beek commented on HTTPCLIENT-2187:
-
So I ran
com.github.tomakehurst.wiremock.JvmProxyConfigAcceptanceTest.configuresHttpsProxyingOnlyFromAWireMockServer()
in this branch: [https://github.com/wiremock/wiremock/pull/1698]
These are the logs:
{code:java}
2021-11-20 22:56:09,340 main ERROR Unable to locate appender "Console" for
logger config "org.apache.hc.client5.http"
2021-11-20 22:56:09,344 main ERROR Unable to locate appender "Console" for
logger config "org.apache.hc.client5.http.wire"
2021-11-20 22:56:09,403 INFO [com.tngtech.archunit.ArchConfiguration] Reading
ArchUnit properties from
file:/home/tim/Documents/workspace/wiremock/bin/test/archunit.properties
2021-11-20 22:56:09,829 INFO [org.eclipse.jetty.util.log] Logging initialized
@1063ms to org.eclipse.jetty.util.log.Slf4jLog
2021-11-20 22:56:10,033 INFO [org.eclipse.jetty.server.Server]
jetty-9.4.44.v20210927; built: 2021-09-27T23:02:44.612Z; git:
8da83308eeca865e495e53ef315a249d63ba9332; jvm 1.8.0_302-b08
2021-11-20 22:56:10,046 INFO [org.eclipse.jetty.server.handler.ContextHandler]
Started o.e.j.s.ServletContextHandler@791cbf87{/__admin,null,AVAILABLE}
2021-11-20 22:56:10,051 INFO
[org.eclipse.jetty.server.handler.ContextHandler.ROOT] RequestHandlerClass from
context returned com.github.tomakehurst.wiremock.http.StubRequestHandler.
Normalized mapped under returned 'null'
2021-11-20 22:56:10,051 INFO [org.eclipse.jetty.server.handler.ContextHandler]
Started o.e.j.s.ServletContextHandler@66971f6b{/,null,AVAILABLE}
2021-11-20 22:56:10,062 INFO [org.eclipse.jetty.server.AbstractConnector]
Started NetworkTrafficServerConnector@1c3b9394{HTTP/1.1, (http/1.1,
h2c)}{0.0.0.0:41447}
2021-11-20 22:56:10,079 INFO [org.eclipse.jetty.server.AbstractConnector]
Started NetworkTrafficServerConnector@54a67a45{SSL, (ssl,
http/1.1)}{0.0.0.0:35709}
2021-11-20 22:56:10,079 INFO [org.eclipse.jetty.server.Server] Started @1314ms
2021-11-20 22:56:10,096 DEBUG
[org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-01
preparing request execution
2021-11-20 22:56:10,100 DEBUG
[org.apache.hc.client5.http.impl.classic.ProtocolExec] ex-01 target
auth state: UNCHALLENGED
2021-11-20 22:56:10,100 DEBUG
[org.apache.hc.client5.http.impl.classic.ConnectExec] ex-01 acquiring
connection with route {tls}->http://localhost:41447->https://example.com:443
2021-11-20 22:56:10,101 DEBUG
[org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-01
acquiring endpoint (3 MINUTES)
2021-11-20 22:56:10,102 DEBUG
[org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager]
ex-01 endpoint lease request (3 MINUTES) [route:
{tls}->http://localhost:41447->https://example.com:443][total available: 0;
route allocated: 0 of 5; total allocated: 0 of 25]
2021-11-20 22:56:10,104 DEBUG
[org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager]
ex-01 endpoint leased [route:
{tls}->http://localhost:41447->https://example.com:443][total available: 0;
route allocated: 1 of 5; total allocated: 1 of 25]
2021-11-20 22:56:10,111 DEBUG
[org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager]
ex-01 acquired ep-00
2021-11-20 22:56:10,112 DEBUG
[org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-01
acquired endpoint ep-00
2021-11-20 22:56:10,112 DEBUG
[org.apache.hc.client5.http.impl.classic.ConnectExec] ex-01 opening
connection {tls}->http://localhost:41447->https://example.com:443
2021-11-20 22:56:10,112 DEBUG
[org.apache.hc.client5.http.impl.classic.InternalHttpClient] ep-00
connecting endpoint (3 MINUTES)
2021-11-20 22:56:10,112 DEBUG
[org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager]
ep-00 connecting endpoint to http://localhost:41447 (3 MINUTES)
2021-11-20 22:56:10,114 DEBUG
[org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator]
http-outgoing-0 connecting to localhost/127.0.0.1:41447
2021-11-20 22:56:10,115 DEBUG
[org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator]
http-outgoing-0 connection established 127.0.0.1:55746<->127.0.0.1:41447
2021-11-20 22:56:10,115 DEBUG
[org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager]
ep-00 connected http-outgoing-0
2021-11-20 22:56:10,115 DEBUG
[org.apache.hc.client5.http.impl.classic.InternalHttpClient] ep-00
endpoint connected
2021-11-20 22:56:10,115 DEBUG
[org.apache.hc.client5.http.impl.io.DefaultManagedHttpClientConnection]
http-outgoing-0 set socket timeout to 3 MILLISECONDS
2021-11-20 22:56:10,115 DEBUG
[org.apache.hc.client5.http.impl.classic.InternalHttpClient] ep-00
start execution ex-01
2021-11-20 22:56:10,115 DEBUG
[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446879#comment-17446879
]
Tim te Beek commented on HTTPCLIENT-2187:
-
Could be; I had looked through the changes but didn't immediately recognize
anything as a possible cause other than the proxy changes.
[https://github.com/apache/httpcomponents-client/compare/rel/v5.1...rel/v5.1.1]
Not too familiar with the httpclient code base to definitively say what the
issue is; feel free to update the title/content if there's a better fitting
description.
> Classic proxy handling for HTTPS seems broken as of 5.1.1+
> --
>
> Key: HTTPCLIENT-2187
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2187
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.1, 5.1.2, 5.2-alpha1
>Reporter: Tim te Beek
>Priority: Major
>
> Classic proxy handling for HTTPS seems to have broken as of 5.1.1+, as seen
> here: [https://github.com/wiremock/wiremock/pull/1698]
> To give just one sample, we now see a failure stacktrace such as this:
> {{java.lang.IllegalStateException: Endpoint is not connected}}
> {{ at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:637)}}
> {{ at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.upgrade(PoolingHttpClientConnectionManager.java:454)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.upgradeTls(InternalExecRuntime.java:190)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:172)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:197)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)}}
> {{ at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:89)}}
> {{ at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.getContent(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:67)}}
> {{ at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.configures_jvm_proxy_and_enables_browser_proxying_https(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:63)}}
> That test basically calls this class to set the System proxy properties:
> [https://github.com/wiremock/wiremock/blob/master/src/main/java/com/github/tomakehurst/wiremock/http/JvmProxyConfigurer.java#L48]
> For HTTP that still works fine, for HTTPS it now fails.
>
> There were some recent changes in 5.1.1 related to proxy handling & keep
> alive for async:
> [https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-2177]
> [https://github.com/apache/httpcomponents-client/compare/50f93ec18be8d6f49138825356051c4c0b60dce4...90f69c87b27b721ea8f0e23bdb4baf92bd7cde06]
> However, we're using classic still, and seeing the error above, so not sure
> it's related.
> Could anyone look into why we are now having these issues with only a patch
> version bump?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446878#comment-17446878
]
Oleg Kalnichevski commented on HTTPCLIENT-2187:
---
[~timtebeek] All our integration tests pass for me locally with 5.1.x HEAD [1].
{noformat}
OK : http://localhost:8080: OPTIONS * -> Server: Apache/2.4.35 (Unix)
OpenSSL/1.1.0f
OK : http://localhost:8080: GET / -> 200
OK : http://localhost:8080: GET /news.html -> 200
OK : http://localhost:8080: GET /status.html -> 200
OK : http://localhost:8080: GET /private/big-secret.txt -> 401 (wrong target
auth scope)
OK : http://localhost:8080: GET /private/big-secret.txt -> 401 (wrong target
creds)
OK : http://localhost:8080: GET /private/big-secret.txt -> 200 (correct target
creds)
OK : http://localhost:8080: GET /private/big-secret.txt -> 200 (correct target
creds / no keep-alive)
OK : http://test-httpd:8080 via http://localhost:: OPTIONS * -> Server:
Apache/2.4.35 (Unix) OpenSSL/1.1.0f
OK : http://test-httpd:8080 via http://localhost:: GET / -> 200
OK : http://test-httpd:8080 via http://localhost:: GET /news.html -> 200
OK : http://test-httpd:8080 via http://localhost:: GET /status.html -> 200
OK : http://test-httpd:8080 via http://localhost:: GET
/private/big-secret.txt -> 401 (wrong target auth scope)
OK : http://test-httpd:8080 via http://localhost:: GET
/private/big-secret.txt -> 401 (wrong target creds)
OK : http://test-httpd:8080 via http://localhost:: GET
/private/big-secret.txt -> 200 (correct target creds)
OK : http://test-httpd:8080 via http://localhost:: GET
/private/big-secret.txt -> 200 (correct target creds / no keep-alive)
OK : http://test-httpd:8080 via http://localhost:8889: OPTIONS * -> Server:
Apache/2.4.35 (Unix) OpenSSL/1.1.0f
OK : http://test-httpd:8080 via http://localhost:8889: GET / -> 200
OK : http://test-httpd:8080 via http://localhost:8889: GET /news.html -> 200
OK : http://test-httpd:8080 via http://localhost:8889: GET /status.html -> 200
OK : http://test-httpd:8080 via http://localhost:8889: GET
/private/big-secret.txt -> 401 (wrong target auth scope)
OK : http://test-httpd:8080 via http://localhost:8889: GET
/private/big-secret.txt -> 401 (wrong target creds)
OK : http://test-httpd:8080 via http://localhost:8889: GET
/private/big-secret.txt -> 200 (correct target creds)
OK : http://test-httpd:8080 via http://localhost:8889: GET
/private/big-secret.txt -> 200 (correct target creds / no keep-alive)
OK : https://localhost:8443: OPTIONS * -> Server: Apache/2.4.35 (Unix)
OpenSSL/1.1.0f
OK : https://localhost:8443: GET / -> 200
OK : https://localhost:8443: GET /news.html -> 200
OK : https://localhost:8443: GET /status.html -> 200
OK : https://localhost:8443: GET /private/big-secret.txt -> 401 (wrong target
auth scope)
OK : https://localhost:8443: GET /private/big-secret.txt -> 401 (wrong target
creds)
OK : https://localhost:8443: GET /private/big-secret.txt -> 200 (correct target
creds)
OK : https://localhost:8443: GET /private/big-secret.txt -> 200 (correct target
creds / no keep-alive)
OK : https://test-httpd:8443 via http://localhost:: OPTIONS * -> Server:
Apache/2.4.35 (Unix) OpenSSL/1.1.0f
OK : https://test-httpd:8443 via http://localhost:: GET / -> 200
OK : https://test-httpd:8443 via http://localhost:: GET /news.html -> 200
OK : https://test-httpd:8443 via http://localhost:: GET /status.html -> 200
OK : https://test-httpd:8443 via http://localhost:: GET
/private/big-secret.txt -> 401 (wrong target auth scope)
OK : https://test-httpd:8443 via http://localhost:: GET
/private/big-secret.txt -> 401 (wrong target creds)
OK : https://test-httpd:8443 via http://localhost:: GET
/private/big-secret.txt -> 200 (correct target creds)
OK : https://test-httpd:8443 via http://localhost:: GET
/private/big-secret.txt -> 200 (correct target creds / no keep-alive)
OK : https://test-httpd:8443 via http://localhost:8889: OPTIONS * -> Server:
Apache/2.4.35 (Unix) OpenSSL/1.1.0f
OK : https://test-httpd:8443 via http://localhost:8889: GET / -> 200
OK : https://test-httpd:8443 via http://localhost:8889: GET /news.html -> 200
OK : https://test-httpd:8443 via http://localhost:8889: GET /status.html -> 200
OK : https://test-httpd:8443 via http://localhost:8889: GET
/private/big-secret.txt -> 401 (wrong target auth scope)
OK : https://test-httpd:8443 via http://localhost:8889: GET
/private/big-secret.txt -> 401 (wrong target creds)
OK : https://test-httpd:8443 via http://localhost:8889: GET
/private/big-secret.txt -> 200 (correct target creds)
OK : https://test-httpd:8443 via http://localhost:8889: GET
/private/big-secret.txt -> 200 (correct target creds / no keep-alive)
{noformat}
Could you please upgrade to 5.1.2, re-run your tests and attach the _complete_
wire log of the session that exhibits the problem [2]?
Oleg
[1]
[jira] [Commented] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446873#comment-17446873
]
Michael Osipov commented on HTTPCLIENT-2187:
This means that {{CONNECT}} does not work?
> Classic proxy handling for HTTPS seems broken as of 5.1.1+
> --
>
> Key: HTTPCLIENT-2187
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2187
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
>Affects Versions: 5.1.1, 5.1.2, 5.2-alpha1
>Reporter: Tim te Beek
>Priority: Major
>
> Classic proxy handling for HTTPS seems to have broken as of 5.1.1+, as seen
> here: https://github.com/wiremock/wiremock/pull/1698
> To give just one sample, we now see a failure stacktrace such as this:
> ```
> java.lang.IllegalStateException: Endpoint is not connected
> at org.apache.hc.core5.util.Asserts.check(Asserts.java:38)
> at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager$InternalConnectionEndpoint.getValidatedPoolEntry(PoolingHttpClientConnectionManager.java:637)
> at
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.upgrade(PoolingHttpClientConnectionManager.java:454)
> at
> org.apache.hc.client5.http.impl.classic.InternalExecRuntime.upgradeTls(InternalExecRuntime.java:190)
> at
> org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:172)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:197)
> at
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
> at
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)
> at
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:89)
> at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.getContent(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:67)
> at
> com.github.tomakehurst.wiremock.junit5.JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.configures_jvm_proxy_and_enables_browser_proxying_https(JUnitJupiterExtensionJvmProxyNonStaticProgrammaticTest.java:63)
> ```
> That test basically calls this class to set the System proxy properties:
> [https://github.com/wiremock/wiremock/blob/master/src/main/java/com/github/tomakehurst/wiremock/http/JvmProxyConfigurer.java#L48]
> For HTTP that still works fine, for HTTPS it now fails.
>
> There were some recent changes in 5.1.1 related to proxy handling & keep
> alive for async:
> [https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-2177]
> [https://github.com/apache/httpcomponents-client/compare/50f93ec18be8d6f49138825356051c4c0b60dce4...90f69c87b27b721ea8f0e23bdb4baf92bd7cde06]
> However, we're using classic still, and seeing the error above, so not sure
> it's related.
> Could anyone look into why we are now having these issues with only a patch
> version bump?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
