[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=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=AKIAYXOCC6LC2SUN5FPM%2F20201019%2Fus-east-1%2Fs3%2Faws4_request=20201019T143034Z=300=host=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=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=AKIAYXOCC6LC2SUN5FPM%2F20201019%2Fus-east-1%2Fs3%2Faws4_request=20201019T143034Z=300=host=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=AKIAYXOCC6LC2SUN5FPM%2F20201019%2Fus-east-1%2Fs3%2Faws4_request=20201019T143034Z=300=host=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=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=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
>
[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=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=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
For additional
[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=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 unsubscribe,
[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=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
>
[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=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(ProtocolExec.java:194)
>
[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=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(AbstractPlainSocketImpl.java:206)
>
[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=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
>
[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=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
>
[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=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.socketConnect(Native Method)
[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
[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
