[jira] [Commented] (HTTPCLIENT-2121) 307 redirect failure with "Premature end of Content-Length delimited message body" when Content-Length given
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216947#comment-17216947 ] Chanseok Oh commented on HTTPCLIENT-2121: - Thanks for your responses! It sounds like getting around this on the Apache side is not the right way and the server should fix it. Feel free to close the bug. > 307 redirect failure with "Premature end of Content-Length delimited message > body" when Content-Length given > > > Key: HTTPCLIENT-2121 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2121 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpCache >Reporter: Chanseok Oh >Priority: Major > > GitHub Container Registry (a Docker registry server) returns "307 Temporary > Redirect" with "Content-Length:" set to a non-zero value but with no body. It > then fails with > {code:java} > Caused by: org.apache.http.ConnectionClosedException: Premature end of > Content-Length delimited message body (expected: 31,167; received: 0) > {code} > At least, the Apache Client could redirect without failing when a response > body is empty for 3xx redirects even if "Content-Length:" is set. > * Sample request: > {code:java} > GET > https://ghcr.io/v2/github/super-linter/blobs/sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7 > Accept: > Accept-Encoding: gzip > Authorization: > {code} > * Sample response: > {code:java} > HTTP/1.1 307 Temporary Redirect > Content-Length: 31167 > Content-Type: application/octet-stream > Docker-Content-Digest: > sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7 > Docker-Distribution-Api-Version: registry/2.0 > Etag: > "sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7" > Location: > https://github-production-container-registry.s3.amazonaws.com/blobs/sha256%3Ac7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAYXOCC6LC2SUN5FPM%2F20201019%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201019T143034Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=b4603c19d939e65e7eb93294ad854095dbe5173daffd2f3344db2eae30ece915 > Date: Mon, 19 Oct 2020 14:30:34 GMT > X-GitHub-Request-Id: CDB2:4010:722EA:118BF2:5F8DA309 > {code} > * Stack trace: > {code:java} > Caused by: org.apache.http.ConnectionClosedException: Premature end of > Content-Length delimited message body (expected: 31,167; received: 0) > at org.apache.http.impl.io.ContentLengthInputStream.read > (ContentLengthInputStream.java:178) > at org.apache.http.impl.io.ContentLengthInputStream.read > (ContentLengthInputStream.java:198) > at org.apache.http.impl.io.ContentLengthInputStream.close > (ContentLengthInputStream.java:101) > at org.apache.http.impl.execchain.ResponseEntityProxy.streamClosed > (ResponseEntityProxy.java:142) > at org.apache.http.conn.EofSensorInputStream.checkClose > (EofSensorInputStream.java:228) > at org.apache.http.conn.EofSensorInputStream.close > (EofSensorInputStream.java:172) > at java.io.FilterInputStream.close (FilterInputStream.java:181) > at com.google.api.client.util.LoggingInputStream.close > (LoggingInputStream.java:67) > at com.google.api.client.http.HttpResponse.ignore (HttpResponse.java:417) > at com.google.api.client.http.HttpRequest.execute (HttpRequest.java:1083) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2121) 307 redirect failure with "Premature end of Content-Length delimited message body" when Content-Length given
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216845#comment-17216845 ] Chanseok Oh commented on HTTPCLIENT-2121: - That is fair. Let me confirm a few things, so that I can report to the GitHub folks. You're suggesting that in order to be compliant to the HTTP sepc, GitHub should either 1. send `Connection: close` (i.e., it's compliant that they set non-zero `Content-Length:` in this case); _OR_ 2. set `Content-Length:` to 0 ? Or ideally both? I fear that 1) may still result in this failure. And is there a workaround (whatever it is) on the side of the Apache client user until the server fixes the issue? For example, there's a configurable option to ignore this issue? > 307 redirect failure with "Premature end of Content-Length delimited message > body" when Content-Length given > > > Key: HTTPCLIENT-2121 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2121 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpCache >Reporter: Chanseok Oh >Priority: Major > > GitHub Container Registry (a Docker registry server) returns "307 Temporary > Redirect" with "Content-Length:" set to a non-zero value but with no body. It > then fails with > {code:java} > Caused by: org.apache.http.ConnectionClosedException: Premature end of > Content-Length delimited message body (expected: 31,167; received: 0) > {code} > At least, the Apache Client could redirect without failing when a response > body is empty for 3xx redirects even if "Content-Length:" is set. > * Sample request: > {code:java} > GET > https://ghcr.io/v2/github/super-linter/blobs/sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7 > Accept: > Accept-Encoding: gzip > Authorization: > {code} > * Sample response: > {code:java} > HTTP/1.1 307 Temporary Redirect > Content-Length: 31167 > Content-Type: application/octet-stream > Docker-Content-Digest: > sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7 > Docker-Distribution-Api-Version: registry/2.0 > Etag: > "sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7" > Location: > https://github-production-container-registry.s3.amazonaws.com/blobs/sha256%3Ac7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAYXOCC6LC2SUN5FPM%2F20201019%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201019T143034Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=b4603c19d939e65e7eb93294ad854095dbe5173daffd2f3344db2eae30ece915 > Date: Mon, 19 Oct 2020 14:30:34 GMT > X-GitHub-Request-Id: CDB2:4010:722EA:118BF2:5F8DA309 > {code} > * Stack trace: > {code:java} > Caused by: org.apache.http.ConnectionClosedException: Premature end of > Content-Length delimited message body (expected: 31,167; received: 0) > at org.apache.http.impl.io.ContentLengthInputStream.read > (ContentLengthInputStream.java:178) > at org.apache.http.impl.io.ContentLengthInputStream.read > (ContentLengthInputStream.java:198) > at org.apache.http.impl.io.ContentLengthInputStream.close > (ContentLengthInputStream.java:101) > at org.apache.http.impl.execchain.ResponseEntityProxy.streamClosed > (ResponseEntityProxy.java:142) > at org.apache.http.conn.EofSensorInputStream.checkClose > (EofSensorInputStream.java:228) > at org.apache.http.conn.EofSensorInputStream.close > (EofSensorInputStream.java:172) > at java.io.FilterInputStream.close (FilterInputStream.java:181) > at com.google.api.client.util.LoggingInputStream.close > (LoggingInputStream.java:67) > at com.google.api.client.http.HttpResponse.ignore (HttpResponse.java:417) > at com.google.api.client.http.HttpRequest.execute (HttpRequest.java:1083) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-2121) 307 redirect failure with "Premature end of Content-Length delimited message body" when Content-Length given
Chanseok Oh created HTTPCLIENT-2121: --- Summary: 307 redirect failure with "Premature end of Content-Length delimited message body" when Content-Length given Key: HTTPCLIENT-2121 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2121 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpCache Reporter: Chanseok Oh GitHub Container Registry (a Docker registry server) returns "307 Temporary Redirect" with "Content-Length:" set to a non-zero value but with no body. It then fails with {code:java} Caused by: org.apache.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 31,167; received: 0) {code} At least, the Apache Client could redirect without failing when a response body is empty for 3xx redirects even if "Content-Length:" is set. * Sample request: {code:java} GET https://ghcr.io/v2/github/super-linter/blobs/sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7 Accept: Accept-Encoding: gzip Authorization: {code} * Sample response: {code:java} HTTP/1.1 307 Temporary Redirect Content-Length: 31167 Content-Type: application/octet-stream Docker-Content-Digest: sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7 Docker-Distribution-Api-Version: registry/2.0 Etag: "sha256:c7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7" Location: https://github-production-container-registry.s3.amazonaws.com/blobs/sha256%3Ac7ac13e5f90fc4ec084e37323433806d2b693ec0954243b5fd1eac938db3c1b7?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAYXOCC6LC2SUN5FPM%2F20201019%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201019T143034Z&X-Amz-Expires=300&X-Amz-SignedHeaders=host&X-Amz-Signature=b4603c19d939e65e7eb93294ad854095dbe5173daffd2f3344db2eae30ece915 Date: Mon, 19 Oct 2020 14:30:34 GMT X-GitHub-Request-Id: CDB2:4010:722EA:118BF2:5F8DA309 {code} * Stack trace: {code:java} Caused by: org.apache.http.ConnectionClosedException: Premature end of Content-Length delimited message body (expected: 31,167; received: 0) at org.apache.http.impl.io.ContentLengthInputStream.read (ContentLengthInputStream.java:178) at org.apache.http.impl.io.ContentLengthInputStream.read (ContentLengthInputStream.java:198) at org.apache.http.impl.io.ContentLengthInputStream.close (ContentLengthInputStream.java:101) at org.apache.http.impl.execchain.ResponseEntityProxy.streamClosed (ResponseEntityProxy.java:142) at org.apache.http.conn.EofSensorInputStream.checkClose (EofSensorInputStream.java:228) at org.apache.http.conn.EofSensorInputStream.close (EofSensorInputStream.java:172) at java.io.FilterInputStream.close (FilterInputStream.java:181) at com.google.api.client.util.LoggingInputStream.close (LoggingInputStream.java:67) at com.google.api.client.http.HttpResponse.ignore (HttpResponse.java:417) at com.google.api.client.http.HttpRequest.execute (HttpRequest.java:1083) {code} -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2015) Connect timeout value is effective doubled
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928736#comment-16928736 ] Chanseok Oh commented on HTTPCLIENT-2015: - Oh, okay. I think I got it but somewhat vaguely. Excuse my ignorance, as I'm not familiar with "multi-home DNS addresses". So, in my test case above, does this mean that my machine has, say, two network cards (NIC or whatever) each assigned a different IP address connecting two different networks and HttpClient tries the first route that times out after 3 seconds and then tries the second route, making the total "timeout" feel like 6 seconds? Or, is it the {{example.com}} host that has two IPs? > Connect timeout value is effective doubled > -- > > Key: HTTPCLIENT-2015 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2015 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.10 > Environment: Debian-based Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Minor > > The connection times out, say, after 6 seconds when calling > `setConnectionTimeout(3000)`. The timeout value is effectively doubled. I've > provided sample code, which demonstrates that the JDK Socket times out after > 3 seconds, but the Apache HTTP Client times out after 6 seconds. > This may seem like a minor bug to others, but our product functionality > depends on timeouts in part and allows the user to adjust the timeouts, and > this timeout-doubling-effect is causing some trouble to us. > {code:java} > public static void main(String[] args) { > long started = System.nanoTime(); > try (Socket socket = new Socket()) { > socket.connect(new InetSocketAddress("example.com", 81), 3000); > } catch (IOException ex) { > ex.printStackTrace(System.out); > } finally { > System.out.println("JDK elapsed (s): " + (System.nanoTime() - started) > / 10L); > } > try (CloseableHttpClient client = HttpClients.createDefault()) { > HttpGet httpGet = new HttpGet("https://example.com:81";); > > httpGet.setConfig(RequestConfig.custom().setConnectTimeout(3000).build()); > long started2 = System.nanoTime(); > try (CloseableHttpResponse res = client.execute(httpGet)) { > } finally { > System.out.println("Apache elapsed (s): " + (System.nanoTime() - > started2) / 10L); > } > } catch (IOException ex) { > ex.printStackTrace(System.out); > } > } > {code} > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-2015) Connect timeout value is effective doubled
Chanseok Oh created HTTPCLIENT-2015: --- Summary: Connect timeout value is effective doubled Key: HTTPCLIENT-2015 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2015 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient (classic) Affects Versions: 4.5.10 Environment: Debian-based Linux openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) Reporter: Chanseok Oh The connection times out, say, after 6 seconds when calling `setConnectionTimeout(3000)`. The timeout value is effectively doubled. I've provided sample code, which demonstrates that the JDK Socket times out after 3 seconds, but the Apache HTTP Client times out after 6 seconds. This may seem like a minor bug to others, but our product functionality depends on timeouts in part and allows the user to adjust the timeouts, and this timeout-doubling-effect is causing some trouble to us. {code:java} public static void main(String[] args) { long started = System.nanoTime(); try (Socket socket = new Socket()) { socket.connect(new InetSocketAddress("example.com", 81), 3000); } catch (IOException ex) { ex.printStackTrace(System.out); } finally { System.out.println("JDK elapsed (s): " + (System.nanoTime() - started) / 10L); } try (CloseableHttpClient client = HttpClients.createDefault()) { HttpGet httpGet = new HttpGet("https://example.com:81";); httpGet.setConfig(RequestConfig.custom().setConnectTimeout(3000).build()); long started2 = System.nanoTime(); try (CloseableHttpResponse res = client.execute(httpGet)) { } finally { System.out.println("Apache elapsed (s): " + (System.nanoTime() - started2) / 10L); } } catch (IOException ex) { ex.printStackTrace(System.out); } } {code} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16922837#comment-16922837 ] Chanseok Oh commented on HTTPCLIENT-2013: - Filed a bug against Oracle JDK a while ago. Just got a message today that they've finished internal review on it, and the bug has been posted today: [https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8230528] Their first comment is what I actually anticipated, since it's obvious {{SocketTimeoutException}} is when by the socket {{SO_TIMEOUT,}} while the {{ConnectException}} timeout case is when the handshake fails at a lower level unrelated to {{SO_TIMEOUT}}. In any case, the situation is confusing enough IMO and it doesn't provide a reliable way to programmatically determine whether a timeout happened, so I'll just hope they are willing to mitigate this somehow. Their priority is P4 though. > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Minor > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(Abstra
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914970#comment-16914970 ] Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/24/19 2:26 PM: -- Great. Keep up the good work. Thanks! was (Author: francium25): Great. Keep up with the good work. > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Minor > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666) > at > org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118) > ... 10 more > {code} > > -- This message was sent by Atlassian Jira (v8.3.2#803003) -
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914970#comment-16914970 ] Chanseok Oh commented on HTTPCLIENT-2013: - Great. Keep up with the good work. > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Minor > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666) > at > org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118) > ... 10 more > {code} > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914696#comment-16914696 ] Chanseok Oh commented on HTTPCLIENT-2013: - Agreed. Now you seem to be on track, great. Thanks! > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Improvement > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Minor > Fix For: 5.0 Beta6 > > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666) > at > org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118) > ... 10 more > {code} > > -- This message was sent by Atlassian Jira (v8.3.2#803003) - To
[jira] [Reopened] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chanseok Oh reopened HTTPCLIENT-2013: - Good. Now it looks like we both understand each other crystal clear with no ambiguity: # It is not that there is a bug in Oracle / OpenJDK that should be fixed. No need to file a bug against them. # The current HttpClient code throws {{ConnectTimeoutException}} (which does not extend {{ConnectException}}) after catching {{ConnectException}} from a Java runtime if the exception message is {{Connection timed out}}. The behavior has been like this for a long time, of course. # However, unlike above, there is an inconsistency that HttpClient confusingly does not throw {{ConnectTimeoutException}} for some {{ConnectionException}} coming from a Java runtime whose exception message contains {{Connection timed out}}. The behavior has been like this for a long time, of course. It is up to you to decide whether you will preserve the current behavior to leave the current inconsistency for the sake of not trying to break many other users depending on the library or you will revisit the whole thing in 5.0 to make things right ideally. But I would humbly suggest you resolve this inconsistency in 5.0. IMHO, it looks like a bug that should be fixed in an ideal world. Whatever you decide, I will reopen the issue for tracking purposes. > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) >
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914500#comment-16914500 ] Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/23/19 5:45 PM: -- What I am saying is that, you catch {{ConnectException}}, but obviously you don't always re-throw it as {{HttpHostConnectException}}, according to the current code. Based on the actual exception message of the caught {{ConnectException}}, you sometimes (are supposed to) throw {{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is triggered only when the exception message is precisely {{Connection timed out}}, which is obviously for the connection timeout case. I am saying that now this is not happening here. If you are to say the current behavior to always throw {{HttpHostConnectException}} is correct, I think it should rather be that you should really take out the following useless/incorrect/dangerous code to check the exception message. {code:java} throw "Connection timed out".equals(msg) ? ... : ... {code} was (Author: francium25): What I am saying is that, you catch {{ConnectException}}, but obviously you don't always re-throw it as {{HttpHostConnectException}}, according to the current code. Based on the actual exception message of the caught {{ConnectException}}, you sometimes (are supposed to) throw {{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is triggered only when the exception message is precisely {{Connection timed out}}, which is obviously for the connection timeout case. I am saying that now this is not happening here. If you are to say the current behavior is correct, I think it should rather be than you should really take out the following useless/incorrect/dangerous code to check the exception message. {code:java} throw "Connection timed out".equals(msg) ? ... : ... {code} > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.ap
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914500#comment-16914500 ] Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/23/19 5:44 PM: -- What I am saying is that, you catch {{ConnectException}}, but obviously you don't always re-throw it as {{HttpHostConnectException}}, according to the current code. Based on the actual exception message of the caught {{ConnectException}}, you sometimes (are supposed to) throw {{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is triggered only when the exception message is precisely {{Connection timed out}}, which is obviously for the connection timeout case. I am saying that now this is not happening here. If you are to say the current behavior is correct, I think it should rather be than you should really take out the following useless/incorrect/dangerous code to check the exception message. {code:java} throw "Connection timed out".equals(msg) ? ... : ... {code} was (Author: francium25): What I am saying is that, you catch {{ConnectException}}, but obviously you don't always re-throw it as {{HttpHostConnectException}}, according to the current code. Based on the actual exception message of the caught {{ConnectException}}, you sometimes (are supposed to) throw {{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is triggered only when the exception is precisely {{Connection timed out}}, which is obviously for the connection timeout case. I am saying that now this is not happening here. If you are to say the current behavior is correct, I think it should rather be than you should really take out the following useless/incorrect/dangerous code to check the exception message. {code:java} throw "Connection timed out".equals(msg) ? ... : ... {code} > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(Protocol
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914500#comment-16914500 ] Chanseok Oh commented on HTTPCLIENT-2013: - What I am saying is that, you catch {{ConnectException}}, but obviously you don't always re-throw it as {{HttpHostConnectException}}, according to the current code. Based on the actual exception message of the caught {{ConnectException}}, you sometimes (are supposed to) throw {{ConnectTimeoutException}}, which is not {{ConnectException}}. And this is triggered only when the exception is precisely {{Connection timed out}}, which is obviously for the connection timeout case. I am saying that now this is not happening here. If you are to say the current behavior is correct, I think it should rather be than you should really take out the following useless/incorrect/dangerous code to check the exception message. {code:java} throw "Connection timed out".equals(msg) ? ... : ... {code} > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketIm
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914490#comment-16914490 ] Chanseok Oh commented on HTTPCLIENT-2013: - Also note again that you DO catch {{java.net.ConnectException}} {code:java} } catch (final ConnectException ex) { if (last) { {code} and then you (are supposed to) throw {{ConnectTimeoutExcepton}} if the message is {{Connection timed out}}, which does not extend {{ConnectException}}. {code:java} throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) {code} > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666) > at > org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSo
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914487#comment-16914487 ] Chanseok Oh commented on HTTPCLIENT-2013: - Ok, to understand this with absolutely zero ambiguity, please let me confirm this: What you are saying is that it is the bug in Oracle / OpenJDK that the exception message of {{java.net.ConnectException}} should be {code:java} Connection timed out {code} instead of {code:java} Connection timed out (Connection timed out) {code} ? > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666) > at > org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251) > at > org.apache.http.impl.conn.HttpClie
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914472#comment-16914472 ] Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/23/19 5:11 PM: -- It is true that the Java runtime throws {{ConnectionException}} with the message {{Connection timed out (Connection timed out)}}. Now please look at the Apache code again I showed you in the bug description carefully. {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} As I said, the intention is obviously to throw {{ConnectTimeoutException}} in this case instead of {{HttpHostConnectException}} when the exception message is {{Connection timed out}}. However, this is not happening. So, the bug is that {{DefaultHttpClientConnectionOperator}} does not throw {{ConnectTimeoutException}}. {{DefaultHttpClientConnectionOperator}} should not re-throw the cause as {{HttpHostConnectException}} but as {{ConnectTimeoutException}}. Does this make it clear? was (Author: francium25): It is true that the Java runtime throws {{ConnectionException}} with the message {{Connection timed out (Connection timed out)}}. Now please look at the Apache code again I showed you in the bug description carefully. {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} As I said, the intention is obviously to throw {{ConnectTimeoutException}} in this case instead of {{HttpHostConnectException}} when the exception message is {{Connection timed out}}. However, this is not happening. So, the bug is that {{DefaultHttpClientConnectionOperator}} does not throw {{ConnectTimeoutException}}. It should not re-throw it as {{HttpHostConnectException}} but as {{ConnectTimeoutException}}. Does this make it clear? > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClien
[jira] [Comment Edited] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914472#comment-16914472 ] Chanseok Oh edited comment on HTTPCLIENT-2013 at 8/23/19 5:09 PM: -- It is true that the Java runtime throws {{ConnectionException}} with the message {{Connection timed out (Connection timed out)}}. Now please look at the Apache code again I showed you in the bug description carefully. {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} As I said, the intention is obviously to throw {{ConnectTimeoutException}} in this case instead of {{HttpHostConnectException}} when the exception message is {{Connection timed out}}. However, this is not happening. So, the bug is that {{DefaultHttpClientConnectionOperator}} does not throw {{ConnectTimeoutException}}. It should not re-throw it as {{HttpHostConnectException}} but as {{ConnectTimeoutException}}. Does this make it clear? was (Author: francium25): It is rue that the Java runtime throws {{ConnectionException}} with the message {{Connection timed out (Connection timed out)}}. Now please look at the Apache code again I showed you in the bug description carefully. {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} As I said, the intention is obviously to throw {{ConnectTimeoutException}} in this case instead of {{HttpHostConnectException}} when the exception message is {{Connection timed out}}. However, this is not happening. So, the bug is that {{DefaultHttpClientConnectionOperator}} does not throw {{ConnectTimeoutException}}. It should not re-throw it as {{HttpHostConnectException}} but as {{ConnectTimeoutException}}. Does this make it clear? > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > or
[jira] [Commented] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16914472#comment-16914472 ] Chanseok Oh commented on HTTPCLIENT-2013: - It is rue that the Java runtime throws {{ConnectionException}} with the message {{Connection timed out (Connection timed out)}}. Now please look at the Apache code again I showed you in the bug description carefully. {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} As I said, the intention is obviously to throw {{ConnectTimeoutException}} in this case instead of {{HttpHostConnectException}} when the exception message is {{Connection timed out}}. However, this is not happening. So, the bug is that {{DefaultHttpClientConnectionOperator}} does not throw {{ConnectTimeoutException}}. It should not re-throw it as {{HttpHostConnectException}} but as {{ConnectTimeoutException}}. Does this make it clear? > Connect timeout throws HttpHostConnectException (ConnectException) instead of > ConnectTimeoutException (IOException) > --- > > Key: HTTPCLIENT-2013 > URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 > Project: HttpComponents HttpClient > Issue Type: Bug > Components: HttpClient (classic) >Affects Versions: 4.5.9 > Environment: Linux > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >Reporter: Chanseok Oh >Priority: Major > > It is obvious from the code in DefaultHttpClientConnectionOperator that it is > supposed to throw ConnectTimeoutException in the case of connection timeout: > {code:java} > } catch (final ConnectException ex) { > if (last) { > final String msg = ex.getMessage(); > throw "Connection timed out".equals(msg) > ? new ConnectTimeoutException(ex, host, addresses) > : new HttpHostConnectException(ex, host, addresses); > } > {code} > Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP > Client), and our production code handling ConnectionException got broken due > to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that > extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException > and not a ConnectionException.) > Java version: > {code} > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > {code} > Example code to reproduce: > {code:java} > public static void main(String[] args) throws IOException { >// example.com is reserved by the DNS standard and will always trigger > timeout >try (CloseableHttpClient client = HttpClients.createDefault(); >CloseableHttpResponse response = client.execute(new > HttpGet("https://example.com:81";))) {} > } > {code} > It currently throws the other exception HttpHostConnectException rather than > the supposed ConnectTimeoutException. > {code} > Exception in thread "main" org.apache.http.conn.HttpHostConnectException: > Connect to example.com:81 [example.com/93.184.216.34, > example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out > (Connection timed out) > at > org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) > at > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) > at > org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) > at > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) > at > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) > at > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) > at > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) > at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) > Caused by: java.net.ConnectException: Connection timed out (Connection timed > out) > at java.net.PlainSocketImpl.socketConnec
[jira] [Updated] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chanseok Oh updated HTTPCLIENT-2013: Description: It is obvious from the code in DefaultHttpClientConnectionOperator that it is supposed to throw ConnectTimeoutException in the case of connection timeout: {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP Client), and our production code handling ConnectionException got broken due to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException and not a ConnectionException.) Java version: {code} openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) {code} Example code to reproduce: {code:java} public static void main(String[] args) throws IOException { // example.com is reserved by the DNS standard and will always trigger timeout try (CloseableHttpClient client = HttpClients.createDefault(); CloseableHttpResponse response = client.execute(new HttpGet("https://example.com:81";))) {} } {code} It currently throws the other exception HttpHostConnectException rather than the supposed ConnectTimeoutException. {code:java} Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to example.com:81 [example.com/93.184.216.34, example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out (Connection timed out)Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to example.com:81 [example.com/93.184.216.34, example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374) at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) at com.example.ApacheHttpClient.main(ApacheHttpClient.java:13) Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) ... 10 more {code} was: It is obvious from the code in DefaultHttpClientConnectionOperator that it is supposed to throw ConnectTimeoutException in the case of connection timeout: {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP Client), and our production code handling ConnectionException got broken due to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException and not a ConnectionException.) Java version: {code} openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) {code} Example code to reproduce: {code:java} public static void main(String[] args) throws
[jira] [Updated] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
[ https://issues.apache.org/jira/browse/HTTPCLIENT-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chanseok Oh updated HTTPCLIENT-2013: Description: It is obvious from the code in DefaultHttpClientConnectionOperator that it is supposed to throw ConnectTimeoutException in the case of connection timeout: {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP Client), and our production code handling ConnectionException got broken due to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException and not a ConnectionException.) Java version: {code} openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) {code} Example code to reproduce: {code:java} public static void main(String[] args) throws IOException { // example.com is reserved by the DNS standard and will always trigger timeout try (CloseableHttpClient client = HttpClients.createDefault(); CloseableHttpResponse response = client.execute(new HttpGet("https://example.com:81";))) {} } {code} It currently throws the other exception HttpHostConnectException rather than the supposed ConnectTimeoutException. {code} Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to example.com:81 [example.com/93.184.216.34, example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:138) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:314) at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:357) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:218) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:194) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at com.example.ApacheHttpClient2.main(ApacheHttpClient2.java:13) Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:666) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:251) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118) ... 10 more {code} was: It is obvious from the code in DefaultHttpClientConnectionOperator that it is supposed to throw ConnectTimeoutException in the case of connection timeout: {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP Client), and our production code handling ConnectionException got broken due to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException and not a ConnectionException.) Java version: {code} openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) {code} Example code to reproduce: {code:java} public static void main(String[] args) throws IOException { // example.com is rese
[jira] [Created] (HTTPCLIENT-2013) Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException)
Chanseok Oh created HTTPCLIENT-2013: --- Summary: Connect timeout throws HttpHostConnectException (ConnectException) instead of ConnectTimeoutException (IOException) Key: HTTPCLIENT-2013 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2013 Project: HttpComponents HttpClient Issue Type: Bug Components: HttpClient (classic) Affects Versions: 4.5.9 Environment: Linux openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) Reporter: Chanseok Oh It is obvious from the code in DefaultHttpClientConnectionOperator that it is supposed to throw ConnectTimeoutException in the case of connection timeout: {code:java} } catch (final ConnectException ex) { if (last) { final String msg = ex.getMessage(); throw "Connection timed out".equals(msg) ? new ConnectTimeoutException(ex, host, addresses) : new HttpHostConnectException(ex, host, addresses); } {code} Recently, we've upgraded Apache HttpClient (indirectly through Google HTTP Client), and our production code handling ConnectionException got broken due to DefaultHttpClientConnectionOperator throwing HttpHostConnectException that extends ConnectionException. (OTOH, ConnectTimeoutException is an IOException and not a ConnectionException.) Java version: {code} openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) {code} Example code to reproduce: {code:java} public static void main(String[] args) throws IOException { // example.com is reserved by the DNS standard and will always trigger timeout try (CloseableHttpClient client = HttpClients.createDefault(); CloseableHttpResponse response = client.execute(new HttpGet("https://example.com:81";))) {} } {code} However, it currently throws the other exception HttpHostConnectException rather than ConnectTimeoutException. {code:java} Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to example.com:81 [example.com/93.184.216.34, example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out (Connection timed out)Exception in thread "main" org.apache.http.conn.HttpHostConnectException: Connect to example.com:81 [example.com/93.184.216.34, example.com/2606:2800:220:1:248:1893:25c8:1946] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374) at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) at com.example.ApacheHttpClient.main(ApacheHttpClient.java:13)Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) ... 10 more {code} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org