[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:8888: OPTIONS * -> Server: 
Apache/2.4.35 (Unix) OpenSSL/1.1.0f
OK : http://test-httpd:8080 via http://localhost:8888: GET / -> 200
OK : http://test-httpd:8080 via http://localhost:8888: GET /news.html -> 200
OK : http://test-httpd:8080 via http://localhost:8888: GET /status.html -> 200
OK : http://test-httpd:8080 via http://localhost:8888: GET 
/private/big-secret.txt -> 401 (wrong target auth scope)
OK : http://test-httpd:8080 via http://localhost:8888: GET 
/private/big-secret.txt -> 401 (wrong target creds)
OK : http://test-httpd:8080 via http://localhost:8888: GET 
/private/big-secret.txt -> 200 (correct target creds)
OK : http://test-httpd:8080 via http://localhost:8888: 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:8888: OPTIONS * -> Server: 
Apache/2.4.35 (Unix) OpenSSL/1.1.0f
OK : https://test-httpd:8443 via http://localhost:8888: GET / -> 200
OK : https://test-httpd:8443 via http://localhost:8888: GET /news.html -> 200
OK : https://test-httpd:8443 via http://localhost:8888: GET /status.html -> 200
OK : https://test-httpd:8443 via http://localhost:8888: GET 
/private/big-secret.txt -> 401 (wrong target auth scope)
OK : https://test-httpd:8443 via http://localhost:8888: GET 
/private/big-secret.txt -> 401 (wrong target creds)
OK : https://test-httpd:8443 via http://localhost:8888: GET 
/private/big-secret.txt -> 200 (correct target creds)
OK : https://test-httpd:8443 via http://localhost:8888: 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] 
https://github.com/apache/httpcomponents-client/blob/5.1.x/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/external/HttpClientCompatibilityTest.java
[2] http://hc.apache.org/httpcomponents-client-5.1.x/logging.html


> 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

Reply via email to