[GitHub] [httpcomponents-client] arturobernalg commented on pull request #327: HTTPCLIENT-2186 - Migrate Test to Unit 5.
arturobernalg commented on pull request #327: URL: https://github.com/apache/httpcomponents-client/pull/327#issuecomment-974766813 > Oh wow yes it's quite a bit more involved; looked into it just now, but the whole hierarchy down from `org.apache.hc.client5.testing.async.AbstractServerTestBase` is a challenge given that scheme is now passed as a constructor argument. No quick fixes there I'm afraid. Hi @timtebeek I tried different things and was impossible. TY -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
This is not a security issue. The implementation of NTLM is just as secure as the Microsoft implementation. That's not terribly secure but that's inherent in their design. Karl On Sat, Nov 20, 2021 at 7:02 PM larry mccay wrote: > This is a concerning statement and I need some additional information to > determine what sort of risk is inherent in the current implementation. > Perhaps we should take those details off list if this is a security issue. > > I'll need to determine whether there are any workarounds or usage patterns > that we can use to ensure that we are safe. > Currently we do not preemptively send tokens and we use our own delegation > tokens after the first authentication. > > > On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov > wrote: > > > Am 2021-11-20 um 20:46 schrieb larry mccay: > > > Hi - > > > > > > I am the Apache Knox PMC chair and a committer on Hadoop and other > > > ecosystem projects. > > > > > > FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. > > > Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or > > > proxyuser pattern within Hadoop it requires all proxies that dispatch > > > requests on behalf of other users to authenticate via Kerberos/SPNEGO. > > > Knox is not the only proxyuser in the ecosystem and likely not the only > > one > > > that is leveraging HttpClient this way. > > > It is used within a huge number of Hadoop deployments both on-prem and > in > > > the cloud and SPNEGO is critical to the security of these deployments. > > > > If this would be critical for security then you would not rely on it. It > > does not complete the security context for you. As sad as it sounds. > > > > I am currently in a project at work where I try to get rid of the Ping > > Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient > > is used, in Spring and JMeter. Maybe this well an opportunity to make it > > right, but this will only land in 5.2.x, maybe 5.1.x if the API allows > it. > > > > M > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
This is a concerning statement and I need some additional information to determine what sort of risk is inherent in the current implementation. Perhaps we should take those details off list if this is a security issue. I'll need to determine whether there are any workarounds or usage patterns that we can use to ensure that we are safe. Currently we do not preemptively send tokens and we use our own delegation tokens after the first authentication. On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov wrote: > Am 2021-11-20 um 20:46 schrieb larry mccay: > > Hi - > > > > I am the Apache Knox PMC chair and a committer on Hadoop and other > > ecosystem projects. > > > > FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. > > Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or > > proxyuser pattern within Hadoop it requires all proxies that dispatch > > requests on behalf of other users to authenticate via Kerberos/SPNEGO. > > Knox is not the only proxyuser in the ecosystem and likely not the only > one > > that is leveraging HttpClient this way. > > It is used within a huge number of Hadoop deployments both on-prem and in > > the cloud and SPNEGO is critical to the security of these deployments. > > If this would be critical for security then you would not rely on it. It > does not complete the security context for you. As sad as it sounds. > > I am currently in a project at work where I try to get rid of the Ping > Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient > is used, in Spring and JMeter. Maybe this well an opportunity to make it > right, but this will only land in 5.2.x, maybe 5.1.x if the API allows it. > > M > > - > 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=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
[GitHub] [httpcomponents-client] timtebeek commented on pull request #327: HTTPCLIENT-2186 - Migrate Test to Unit 5.
timtebeek commented on pull request #327: URL: https://github.com/apache/httpcomponents-client/pull/327#issuecomment-974721351 Oh wow yes it's quite a bit more involved; looked into it just now, but the whole hierarchy down from `org.apache.hc.client5.testing.async.AbstractServerTestBase` is a challenge given that scheme is now passed as a constructor argument. No quick fixes there I'm afraid. :disappointed: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - 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
[GitHub] [httpcomponents-client] ok2c commented on pull request #327: HTTPCLIENT-2186 - Migrate Test to Unit 5.
ok2c commented on pull request #327: URL: https://github.com/apache/httpcomponents-client/pull/327#issuecomment-974716993 > Noticed you're using `@EnableRuleMigrationSupport` to retain `@RunWith(Parameterized.class)`. Are you aware of [this automated JUnit Jupiter migration for Parameterized] @timtebeek I did attempt to port our parameterized tests to JUnit 5 approximately 6 months back and failed. There was simply no way (I could find or think of) to parameterize resource rules with JUnit 5. Any chance you could upgrade just one test case to demonstrate how it can be done? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - 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=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] [Updated] (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:all-tabpanel
]
Tim te Beek updated HTTPCLIENT-2187:
Description:
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?
was:
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
[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
[jira] [Created] (HTTPCLIENT-2187) Classic proxy handling for HTTPS seems broken as of 5.1.1+
Tim te Beek created HTTPCLIENT-2187: --- Summary: 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.2-alpha1, 5.1.2, 5.1.1 Reporter: Tim te Beek 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
[GitHub] [httpcomponents-client] timtebeek commented on pull request #327: HTTPCLIENT-2186 - Migrate Test to Unit 5.
timtebeek commented on pull request #327: URL: https://github.com/apache/httpcomponents-client/pull/327#issuecomment-974708950 Noticed you're using `@EnableRuleMigrationSupport` to retain `@RunWith(Parameterized.class)`. Are you aware of [this automated JUnit Jupiter migration for Parameterized](https://docs.openrewrite.org/reference/recipes/java/testing/junit5/parameterizedrunnertoparameterized) using OpenRewrite? They even have [a full migration that you can apply](https://docs.openrewrite.org/tutorials/migrate-from-junit-4-to-junit-5). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 20:46 schrieb larry mccay: Hi - I am the Apache Knox PMC chair and a committer on Hadoop and other ecosystem projects. FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or proxyuser pattern within Hadoop it requires all proxies that dispatch requests on behalf of other users to authenticate via Kerberos/SPNEGO. Knox is not the only proxyuser in the ecosystem and likely not the only one that is leveraging HttpClient this way. It is used within a huge number of Hadoop deployments both on-prem and in the cloud and SPNEGO is critical to the security of these deployments. If this would be critical for security then you would not rely on it. It does not complete the security context for you. As sad as it sounds. I am currently in a project at work where I try to get rid of the Ping Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient is used, in Spring and JMeter. Maybe this well an opportunity to make it right, but this will only land in 5.2.x, maybe 5.1.x if the API allows it. M - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Hi - I am the Apache Knox PMC chair and a committer on Hadoop and other ecosystem projects. FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or proxyuser pattern within Hadoop it requires all proxies that dispatch requests on behalf of other users to authenticate via Kerberos/SPNEGO. Knox is not the only proxyuser in the ecosystem and likely not the only one that is leveraging HttpClient this way. It is used within a huge number of Hadoop deployments both on-prem and in the cloud and SPNEGO is critical to the security of these deployments. We are currently on 4.5.13 for HttpClient. A backward compatible path forward here is going to be needed and I'd be happy to help out however I can. thanks, --larry On Sat, Nov 20, 2021 at 2:08 PM Michael Osipov wrote: > Am 2021-11-20 um 19:35 schrieb Oleg Kalnichevski: > > On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: > >> These protocols are, unfortunately, still used. > >> > >> However, the projects I know that use them have not yet moved to 5.x > >> of > >> httpcomponents. Other projects I know of that used to use > >> httpcomponents > >> have since upgraded to different http libraries that supported http > >> 2.0 > >> early on. > >> > >> The hint that all it takes is a shove from below to convince other > >> projects > >> to drop NTLM support is, perhaps, not accurate. Projects that > >> maintain > >> NTLM support do so because they are tied to legacy systems that use > >> it. > >> Later improvements, e.g. Kerberos, have also only lightly been > >> supported by > >> HttpComponents, and only with external configuration, which really > >> limits > >> its utility. ManifoldCF, which does much integration with windows > >> systems, supports Kerberos but only in the most hacky way, because > >> there > >> wasn't anything more seamless available. > >> > >> I would therefore counter-propose that Kerberos become a first-class > >> replacement to NTLM before NTLM is discontinued. By first-class, I > >> mean > >> that it is possible to programmatically set up a kerberos connection > >> without an external config file. Maybe this is now possible; if so > >> please > >> correct me. > >> > >> I would love to be able to contribute to this effort, but I fear my > >> day > >> job's responsibilities are so vast and growing that this will be > >> impossible. At best I can maintain the projects I have; new > >> development is > >> out of the question at the moment. > >> > >> Karl > >> > > > > Hi Karl > > > > I am so happy that you are still keeping an eye on the mailing list and > > reacting on NTLM related matters. > > > > I do understand your position. The problem is there are no volunteers > > eager to do work on Kerberos support either. We cannot keep on > > pretending everything is all right. We need to make downstream projects > > aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in > > features by default would be the right thing to do in my opinion. > > FWIW, I have explicitly configured auth schemes in Wagon to those known > to work (except NTLM): https://issues.apache.org/jira/browse/WAGON-539 > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 19:35 schrieb Oleg Kalnichevski: On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: These protocols are, unfortunately, still used. However, the projects I know that use them have not yet moved to 5.x of httpcomponents. Other projects I know of that used to use httpcomponents have since upgraded to different http libraries that supported http 2.0 early on. The hint that all it takes is a shove from below to convince other projects to drop NTLM support is, perhaps, not accurate. Projects that maintain NTLM support do so because they are tied to legacy systems that use it. Later improvements, e.g. Kerberos, have also only lightly been supported by HttpComponents, and only with external configuration, which really limits its utility. ManifoldCF, which does much integration with windows systems, supports Kerberos but only in the most hacky way, because there wasn't anything more seamless available. I would therefore counter-propose that Kerberos become a first-class replacement to NTLM before NTLM is discontinued. By first-class, I mean that it is possible to programmatically set up a kerberos connection without an external config file. Maybe this is now possible; if so please correct me. I would love to be able to contribute to this effort, but I fear my day job's responsibilities are so vast and growing that this will be impossible. At best I can maintain the projects I have; new development is out of the question at the moment. Karl Hi Karl I am so happy that you are still keeping an eye on the mailing list and reacting on NTLM related matters. I do understand your position. The problem is there are no volunteers eager to do work on Kerberos support either. We cannot keep on pretending everything is all right. We need to make downstream projects aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in features by default would be the right thing to do in my opinion. FWIW, I have explicitly configured auth schemes in Wagon to those known to work (except NTLM): https://issues.apache.org/jira/browse/WAGON-539 - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 18:25 schrieb Karl Wright: These protocols are, unfortunately, still used. ManifoldCF, which does much integration with windows systems, supports Kerberos but only in the most hacky way, because there wasn't anything more seamless available. I would therefore counter-propose that Kerberos become a first-class replacement to NTLM before NTLM is discontinued. By first-class, I mean that it is possible to programmatically set up a kerberos connection without an external config file. Maybe this is now possible; if so please correct me. Yes, this is impossible. Even impossible with MIT Kerberos. You must have at least a krb5.conf and a JAAS login file. Read further. I would love to be able to contribute to this effort, but I fear my day job's responsibilities are so vast and growing that this will be impossible. At best I can maintain the projects I have; new development is out of the question at the moment. This is purely a Java problem, not a Kerberos problem. The configuration is inevitable because Java is portable otherwise you need to resort to native APIs, e.g., JNA/JNA to SSPI or MIT Kerberos, but that would require custom authenticators. There is now a SSPI binding/implementation for JGSS, but it is not good. I told this Weijun Wang already, but he's the only one at Oracle who is working on this, read busy (read my mails on security-dev). Another huge issue is that stupid JAAS/LoginModule/Subjec thing in Java. It does not have the credential acquision API [1], [2] which MIT Kerberos introduced many years ago, plus in does not even interact to store tickets on the local FILE cache. I'd love to solve all of these issues, but it cannot just be me in the Java world to solve a problem for miliions of devs. Nico Williams of Six Sigma had bright ideas, but very little time. Michael [1] https://pythongssapi.github.io/python-gssapi/stable/gssapi.raw.html#module-gssapi.raw.ext_cred_store [2] https://pythongssapi.github.io/python-gssapi/stable/gssapi.raw.html#module-gssapi.raw.ext_password - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 17:41 schrieb Oleg Kalnichevski: Folks Presently NTLM & SPNEGO are stated as supported authentication schemes, by the project which is, quite frankly, not the case. There are partial implementations in various state of decay contributed some while ago by contributors long gone with no one on the project both capable and willing to maintain that code and deal with user reported issues. I think we should drop the pretense and start dealing with the problem. If we cannot adequately support those features we should consider deprecating and eventually removing them entirely. As the first step I would like to propose NTLM & SPNEGO be made an opt- in feature as of version 5.3. Users would have to explicitly enable NTLM & SPNEGO support to make HttpClient engage in an NTLM or SPNEGO handshake. This may encourage people vested in NTLM and SPNEGO come forth and help support those features. Also, the deprecation or removal of NTLM would unable us to drop connection state tracking support and greatly simplify the connection management APIs. Let me both comment since I have experience with them and on contributions in general. Contributions: I generally, for all ASF projects I maintain, reject contributions I cannot test or do not have access to the technology to do so (it must be freely, namely OSS). I have recently deleted 130 000 LoC in Maven SCM for commercial SCMs because none of us is able to test them. Now let's get into those two: NTLM: Although the client part is fully documented these days, this mechanism is very problematic in many ways. It is connection-bound and generally not suited for HTTP which is stateless, in fact IIS disabled it on HTTP/2 for obvious reasons. There is no OSS implementation (at least I am not aware of) on the server-side (if you put apart innards of Samba) which gives me the ability to hook into Apache HTTPd or Tomcat, ideally as an opaque GSS-API or jGSS mechanism and test properly. You always need a domain controller, ideally Active Directory and a Windows server with IIS to test this. The server needs to talk to the DC likely through MS-RPC (DCE-RPC) (part of the protocol). There is no way I am going to do this. Only SSPI supports this out of the box. Moreover, the mechanism is deprecated for many years by Microsoft and replaced with standard Kerberos. If your company hasn't moved to Kerberos or client certs then something is seriously wrong with your company. My verdict: There is no way we can make this right/reliable/correct. If you check MS-NLMP [1] there are constant updates putting a burden on us. I support its removal in 6.0. SPNEGO: This is a pseudo-mechanism negotiating sub-mechanisms (NTLM or Kerberos). Although a Microsoft invention also, this has an RFC and is completely open. When I talk about SPNEGO I always mean Kerberos negotiated, nothing else. Pure Kerberos does *not* exist over HTTP, thus no need to support it. Kerberos is freely available (for all OSes) and a KDC can be set up with MIT Kerberos, Heimdal or Samba or GNU/Linux or FreeBSD to test. I have a test network in VirtualBox which just works. It is just effort for the implementor to do so, but easier than brain surgery. SPNEGO/Kerberos does *not* require any connection binding, I have been using it for more than 10 years and I have *never* seen more than one roundtrip, see also [2]. Neither with MIT Kerberos, Microsoft Kerberos or Java Kerberos. One of the biggest problems with many OSS approaches I have seen on the client side: they are crap and logically broken. Namely, they violate RFC 7546 [3] and don't make things right. Even curl is broken [3]. The only OSS library I know to be correct is libserf. Many just don't read the RFCs to make things right, compared to you! Ping Identity is also broken. I told this to our service support at work, he was pissed off. 6,5 years I ago I have created HTTPCLIENT-1625 to make things right, 4.x flow was not suitable, in 5.x this was reworked and I believe it will work, but don't know for sure. Shamely, I haven't had enough free time to tackle this issue, I am requirements-driven from work after all and didn't have this one for Java in all those years, clients were in C or C#. Both the JGSS code and the JNA-based code for SSPI aren't really good. As soon as a business need arises here at work, I will start working on it. What is important to know for you when you want to remove code: The security context loop is always client initiated and required to be completed by a token sent from the server with the response unless it is 401/407. So the HttpClient needs to store the context somewhere until it receives the response, completes security context and frees the security context. This is on a per-request basis. If the context is not completed with the response then the authentication should not be trusted, either an exception should be through or a warning/error must be logged. My verdict:
Re: Gradual deprecation and removal of NTLM and SPNEGO support
On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: > These protocols are, unfortunately, still used. > > However, the projects I know that use them have not yet moved to 5.x > of > httpcomponents. Other projects I know of that used to use > httpcomponents > have since upgraded to different http libraries that supported http > 2.0 > early on. > > The hint that all it takes is a shove from below to convince other > projects > to drop NTLM support is, perhaps, not accurate. Projects that > maintain > NTLM support do so because they are tied to legacy systems that use > it. > Later improvements, e.g. Kerberos, have also only lightly been > supported by > HttpComponents, and only with external configuration, which really > limits > its utility. ManifoldCF, which does much integration with windows > systems, supports Kerberos but only in the most hacky way, because > there > wasn't anything more seamless available. > > I would therefore counter-propose that Kerberos become a first-class > replacement to NTLM before NTLM is discontinued. By first-class, I > mean > that it is possible to programmatically set up a kerberos connection > without an external config file. Maybe this is now possible; if so > please > correct me. > > I would love to be able to contribute to this effort, but I fear my > day > job's responsibilities are so vast and growing that this will be > impossible. At best I can maintain the projects I have; new > development is > out of the question at the moment. > > Karl > Hi Karl I am so happy that you are still keeping an eye on the mailing list and reacting on NTLM related matters. I do understand your position. The problem is there are no volunteers eager to do work on Kerberos support either. We cannot keep on pretending everything is all right. We need to make downstream projects aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in features by default would be the right thing to do in my opinion. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
These protocols are, unfortunately, still used. However, the projects I know that use them have not yet moved to 5.x of httpcomponents. Other projects I know of that used to use httpcomponents have since upgraded to different http libraries that supported http 2.0 early on. The hint that all it takes is a shove from below to convince other projects to drop NTLM support is, perhaps, not accurate. Projects that maintain NTLM support do so because they are tied to legacy systems that use it. Later improvements, e.g. Kerberos, have also only lightly been supported by HttpComponents, and only with external configuration, which really limits its utility. ManifoldCF, which does much integration with windows systems, supports Kerberos but only in the most hacky way, because there wasn't anything more seamless available. I would therefore counter-propose that Kerberos become a first-class replacement to NTLM before NTLM is discontinued. By first-class, I mean that it is possible to programmatically set up a kerberos connection without an external config file. Maybe this is now possible; if so please correct me. I would love to be able to contribute to this effort, but I fear my day job's responsibilities are so vast and growing that this will be impossible. At best I can maintain the projects I have; new development is out of the question at the moment. Karl On Sat, Nov 20, 2021 at 11:42 AM Oleg Kalnichevski wrote: > Folks > > Presently NTLM & SPNEGO are stated as supported authentication schemes, > by the project which is, quite frankly, not the case. There are partial > implementations in various state of decay contributed some while ago by > contributors long gone with no one on the project both capable and > willing to maintain that code and deal with user reported issues. > > I think we should drop the pretense and start dealing with the problem. > If we cannot adequately support those features we should consider > deprecating and eventually removing them entirely. > > As the first step I would like to propose NTLM & SPNEGO be made an opt- > in feature as of version 5.3. Users would have to explicitly enable > NTLM & SPNEGO support to make HttpClient engage in an NTLM or SPNEGO > handshake. > > This may encourage people vested in NTLM and SPNEGO come forth and help > support those features. > > Also, the deprecation or removal of NTLM would unable us to drop > connection state tracking support and greatly simplify the connection > management APIs. > > Oleg > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Gradual deprecation and removal of NTLM and SPNEGO support
Folks Presently NTLM & SPNEGO are stated as supported authentication schemes, by the project which is, quite frankly, not the case. There are partial implementations in various state of decay contributed some while ago by contributors long gone with no one on the project both capable and willing to maintain that code and deal with user reported issues. I think we should drop the pretense and start dealing with the problem. If we cannot adequately support those features we should consider deprecating and eventually removing them entirely. As the first step I would like to propose NTLM & SPNEGO be made an opt- in feature as of version 5.3. Users would have to explicitly enable NTLM & SPNEGO support to make HttpClient engage in an NTLM or SPNEGO handshake. This may encourage people vested in NTLM and SPNEGO come forth and help support those features. Also, the deprecation or removal of NTLM would unable us to drop connection state tracking support and greatly simplify the connection management APIs. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on pull request #331: HTTPCORE-698 - Migrate Test to Unit 5.
ok2c commented on pull request #331: URL: https://github.com/apache/httpcomponents-core/pull/331#issuecomment-974657699 > can I help you? @arturobernalg No immediate help is needed. But if you really want to help, please spend less time changing code style based on personal taste or preferences and spend more time improving functionality. For instance, migrating HttpClient APIs from `java.util.Date` to `java.time.Instant` would make a very good contribution.. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-698) Migrate Test to Unit 5
[ https://issues.apache.org/jira/browse/HTTPCORE-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446831#comment-17446831 ] ASF subversion and git services commented on HTTPCORE-698: -- Commit 8b02bdf8e0421d455008bc6d2e367b126721c2ed in httpcomponents-core's branch refs/heads/master from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=8b02bdf ] HTTPCORE-698 - Migrate Test to Unit 5. > Migrate Test to Unit 5 > -- > > Key: HTTPCORE-698 > URL: https://issues.apache.org/jira/browse/HTTPCORE-698 > Project: HttpComponents HttpCore > Issue Type: Improvement >Reporter: Arturo Bernal >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > > Now that we had migrated the httpcomponet to java 1.8. we can migrate the > test to JUnit 5. > I´m gonna create the same for the client module. > Create this to register the work and the progress. > > The only doubt that I have is, do we still want using Hamcrest libs or we > want to replace it in favor of JUnit 5, or just manteing both? > -- 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
[GitHub] [httpcomponents-core] ok2c merged pull request #331: HTTPCORE-698 - Migrate Test to Unit 5.
ok2c merged pull request #331: URL: https://github.com/apache/httpcomponents-core/pull/331 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] michael-o commented on pull request #331: HTTPCORE-698 - Migrate Test to Unit 5.
michael-o commented on pull request #331: URL: https://github.com/apache/httpcomponents-core/pull/331#issuecomment-974653459 > @arturobernalg Looks good to me. > > > Guys, I am still not sure whether this is the right decision for now since we are likely going to maintain 5.1.x on Java 7 for some time... This change will make backports harder. WDYT? > > @michael-o We already started using lambdas in tests, so automatic merging between branches is going to be difficult anyway. so, I do not see this as a deal breaker. Then go on with the merge -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on pull request #331: HTTPCORE-698 - Migrate Test to Unit 5.
arturobernalg commented on pull request #331: URL: https://github.com/apache/httpcomponents-core/pull/331#issuecomment-974653321 > @arturobernalg Looks good to me. > > > Guys, I am still not sure whether this is the right decision for now since we are likely going to maintain 5.1.x on Java 7 for some time... This change will make backports harder. WDYT? > > @michael-o We already started using lambdas in tests, so automatic merging between branches is going to be difficult anyway. so, I do not see this as a deal breaker. can I help you? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on pull request #331: HTTPCORE-698 - Migrate Test to Unit 5.
ok2c commented on pull request #331: URL: https://github.com/apache/httpcomponents-core/pull/331#issuecomment-974652865 @arturobernalg Looks good to me. > Guys, I am still not sure whether this is the right decision for now since we are likely going to maintain 5.1.x on Java 7 for some time... This change will make backports harder. WDYT? @michael-o We already started using lambdas in tests, so automatic merging between branches is going to be difficult anyway. so, I do not see this as a deal breaker. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
arturobernalg commented on pull request #333: URL: https://github.com/apache/httpcomponents-core/pull/333#issuecomment-974652486 > @arturobernalg Please also close the associated JIRA. done. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Closed] (HTTPCORE-700) HttpHost genetic constructor NamedEndpoint
[
https://issues.apache.org/jira/browse/HTTPCORE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal closed HTTPCORE-700.
--
Resolution: Won't Do
Won't do. it can lead to incorrect / unpredictable results.
> HttpHost genetic constructor NamedEndpoint
>
>
> Key: HTTPCORE-700
> URL: https://issues.apache.org/jira/browse/HTTPCORE-700
> Project: HttpComponents HttpCore
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Allow create an instance of HttpHost with an any implementations of
> NamedEndpoint. Now we are able create HttpHost with the next
> implementations:
> {code:java}
> * Host
> * URIAuthority --> already implemented.
> * org.apache.hc.core5.reactor.EndpointParameters{code}
--
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
[GitHub] [httpcomponents-core] ok2c commented on pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
ok2c commented on pull request #333: URL: https://github.com/apache/httpcomponents-core/pull/333#issuecomment-974651675 @arturobernalg Please also close the associated JIRA. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg closed pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
arturobernalg closed pull request #333: URL: https://github.com/apache/httpcomponents-core/pull/333 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
arturobernalg commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753675344
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
OK.
Close the PR:
TY
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
ok2c commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753674363
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
No, not nothing. I am going to deprecate `public HttpHost(final
URIAuthority authority)`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
ok2c commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753673296
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
> I know. but it the same whit the Authority constructor
@arturobernalg It is not the same. The URI authority does not have a scheme
component.
> What you suggest that we should do?
I suggest that we do nothing. Not only this constructor is not very useful,
it can lead to incorrect / unpredictable results.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
arturobernalg commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753672231
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
HI @ok2c
I know. but it the same whit the Authority constructor.->
`public HttpHost(final URIAuthority authority)`
That is why the javadoc say it created with the Default scheme
What you suggest that we should do?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
arturobernalg commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753672231
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
HI @ok2c
I know. but it the same whit the Authority constructor.->
`public HttpHost(final URIAuthority authority)`
What you suggest that we should do?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
arturobernalg commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753672231
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
HI @ok2c
I know. but it the same whit ->
`public HttpHost(final URIAuthority authority)`
What you suggest that we should do?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on a change in pull request #333: HTTPCORE-700 - HttpHost genetic constructor NamedEndpoint
ok2c commented on a change in pull request #333:
URL:
https://github.com/apache/httpcomponents-core/pull/333#discussion_r753662822
##
File path: httpcore5/src/test/java/org/apache/hc/core5/http/TestHttpHost.java
##
@@ -69,6 +73,27 @@ public void testConstructor() {
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (String) null, -1));
Assert.assertThrows(IllegalArgumentException.class, () -> new
HttpHost(null, " ", -1));
Assert.assertThrows(NullPointerException.class, () -> new
HttpHost(null, (InetAddress) null, -1));
+
+final Host host = new Host("myHost", 8080);
Review comment:
@arturobernalg Please add a test case with non-default scheme such as
`https`. I suspect there will be an unpleasant surprise.
##
File path: httpcore5/src/main/java/org/apache/hc/core5/http/HttpHost.java
##
@@ -255,6 +255,22 @@ public HttpHost(final URIAuthority authority) {
this(null, authority);
}
+/**
+ * Creates {@code HttpHost} instance with the default scheme and the given
{@link
+ * NamedEndpoint}
+ *
+ * @throws IllegalArgumentException If the port parameter is outside the
specified range of
+ * valid port values, which is between 0
and 65535, inclusive.
+ * {@code -1} indicates the scheme
default port.
+ * @see Host
+ * @see URIAuthority
+ * @see org.apache.hc.core5.reactor.EndpointParameters
Review comment:
@arturobernalg This looks wrong
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on pull request #332: Do not explicitly declare runtime exceptions.
ok2c commented on pull request #332: URL: https://github.com/apache/httpcomponents-core/pull/332#issuecomment-974627983 I can and I do because I find explicit declaration of exceptions more useful than javadocs. The above statement from Oracle is silly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg commented on pull request #332: Do not explicitly declare runtime exceptions.
arturobernalg commented on pull request #332: URL: https://github.com/apache/httpcomponents-core/pull/332#issuecomment-974617494 https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html "Having to add runtime exceptions in every method declaration would reduce a program's clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can)." -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCORE-700) HttpHost genetic constructor NamedEndpoint
Arturo Bernal created HTTPCORE-700:
--
Summary: HttpHost genetic constructor NamedEndpoint
Key: HTTPCORE-700
URL: https://issues.apache.org/jira/browse/HTTPCORE-700
Project: HttpComponents HttpCore
Issue Type: Improvement
Reporter: Arturo Bernal
Allow create an instance of HttpHost with an any implementations of
NamedEndpoint. Now we are able create HttpHost with the next implementations:
{code:java}
* Host
* URIAuthority --> already implemented.
* org.apache.hc.core5.reactor.EndpointParameters{code}
--
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
