[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcelo Cenerino updated HTTPCLIENT-1940:
-----------------------------------------
    Description: 
We are upgrading httpclient from 4.2.3 to 4.5.3. We wanted to do the upgrade in 
steps: first we just bump the versions and then we gradually refactor the 
existing code to use the new builder-based api.

It turns out that there is a behavior change in 
"org.apache.http.conn.ssl.SSLSocketFactory" (which is deprecated in 4.3+): in 
case of a connect timeout, it does not translate the exception to 
ConnectTimeoutException. This is inconsistent with the also deprecated 
"org.apache.http.conn.scheme.PlainSocketFactory". In the 4.2.x series, the 
exception used to be converted. These are likely the commits that introduced 
this bug:
 * Exception translation moved to an abstract class: 
[https://github.com/apache/httpcomponents-client/commit/e34e868ddc96b873a09b20e4911bc64fe8caf069#diff-2b61663f90e19b0024cea23ce9e5e791]
 * Abstract class removed without moving the exception translation code back to 
SSLSocketFactory: 
[https://github.com/apache/httpcomponents-client/commit/d04b7baa642e7192bddb8e0ad26c7504c6908c85#diff-2b61663f90e19b0024cea23ce9e5e791]

 

I attached a test that reproduces the bug: [^ConnectExceptionTest.java]

This bug is not reproducible with the new builder api. However, given that the 
old api was kept to maintain backwards compatibility, it is reasonable to 
expect the old behavior.

As workarounds to this issue, one can either update the code and use the new 
api or catch the java.net.SocketTimeoutException and check that the message is 
"connect timed out".

Given that the bug hides in deprecated code and there are workarounds, maybe it 
is not worth fixing it. In that case, please feel free to close this issue. 
Otherwise, I can submit a patch.

  was:
We are upgrading httpclient from 4.2.3 to 4.5.3. We wanted to do the upgrade in 
steps: first we just bump the versions and then we gradually refactor the 
existing code to use the new builder-based api.

It turns out that there is a behavior change in 
"org.apache.http.conn.ssl.SSLSocketFactory" (which is deprecated in 4.3+): in 
case of a connect timeout, it does not translate the exception to 
ConnectTimeoutException. This is inconsistent with the also deprecated 
"org.apache.http.conn.scheme.PlainSocketFactory". In the 4.2.x series, the 
exception was converted. These are likely the commits that caused this change:
 * Exception translation moved to an abstract class: 
[https://github.com/apache/httpcomponents-client/commit/e34e868ddc96b873a09b20e4911bc64fe8caf069#diff-2b61663f90e19b0024cea23ce9e5e791]
 * Abstract class removed without moving the exception translation code back to 
SSLSocketFactory: 
[https://github.com/apache/httpcomponents-client/commit/d04b7baa642e7192bddb8e0ad26c7504c6908c85#diff-2b61663f90e19b0024cea23ce9e5e791]

 

I attached a test that reproduces the bug: [^ConnectExceptionTest.java]

This bug is not reproducible with the new builder api. However, given that the 
old api was kept to maintain backwards compatibility, it is reasonable to 
expect the old behavior.

As workarounds to this issue, one can either update the code and use the new 
api or catch the java.net.SocketTimeoutException and check that the message is 
"connect timed out".

Given that the bug hides in deprecated code and there are workarounds, maybe it 
is not worth fixing it. In that case, please feel free to close this issue. 
Otherwise, I can submit a patch.


> org.apache.http.conn.ssl.SSLSocketFactory no longer throws 
> ConnectTimeoutException
> ----------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1940
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1940
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.3
>            Reporter: Marcelo Cenerino
>            Priority: Major
>         Attachments: ConnectExceptionTest.java
>
>
> We are upgrading httpclient from 4.2.3 to 4.5.3. We wanted to do the upgrade 
> in steps: first we just bump the versions and then we gradually refactor the 
> existing code to use the new builder-based api.
> It turns out that there is a behavior change in 
> "org.apache.http.conn.ssl.SSLSocketFactory" (which is deprecated in 4.3+): in 
> case of a connect timeout, it does not translate the exception to 
> ConnectTimeoutException. This is inconsistent with the also deprecated 
> "org.apache.http.conn.scheme.PlainSocketFactory". In the 4.2.x series, the 
> exception used to be converted. These are likely the commits that introduced 
> this bug:
>  * Exception translation moved to an abstract class: 
> [https://github.com/apache/httpcomponents-client/commit/e34e868ddc96b873a09b20e4911bc64fe8caf069#diff-2b61663f90e19b0024cea23ce9e5e791]
>  * Abstract class removed without moving the exception translation code back 
> to SSLSocketFactory: 
> [https://github.com/apache/httpcomponents-client/commit/d04b7baa642e7192bddb8e0ad26c7504c6908c85#diff-2b61663f90e19b0024cea23ce9e5e791]
>  
> I attached a test that reproduces the bug: [^ConnectExceptionTest.java]
> This bug is not reproducible with the new builder api. However, given that 
> the old api was kept to maintain backwards compatibility, it is reasonable to 
> expect the old behavior.
> As workarounds to this issue, one can either update the code and use the new 
> api or catch the java.net.SocketTimeoutException and check that the message 
> is "connect timed out".
> Given that the bug hides in deprecated code and there are workarounds, maybe 
> it is not worth fixing it. In that case, please feel free to close this 
> issue. Otherwise, I can submit a patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to