[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142005#comment-17142005
 ] 

Dave Moten commented on HTTPCLIENT-2090:
----------------------------------------

Righto, from my home machine (no proxy) I made a connection to 
https://google.com and put in a breakpoint at the point it did 
startHandshake(). I stepped back through the stack trace and saw that the 
RequestConfig.connectTimeout had been set as the soTimeout on the sslsocket!

I see the line `final int timeout = config.getConnectTimeout();` in 
MainClientExec.java:383 where config is RequestConfig and that value is passed 
all the way through to the sslsocket. I assume you don't expect this?

Stack trace:
                        SSLConnectionSocketFactory.createLayeredSocket(Socket, 
String, int, HttpContext) line: 436      
                        SSLConnectionSocketFactory.connectSocket(int, Socket, 
HttpHost, InetSocketAddress, InetSocketAddress, HttpContext) line: 384    
                        
DefaultHttpClientConnectionOperator.connect(ManagedHttpClientConnection, 
HttpHost, InetSocketAddress, int, SocketConfig, HttpContext) line: 142 
                        
PoolingHttpClientConnectionManager.connect(HttpClientConnection, HttpRoute, 
int, HttpContext) line: 376 
                        MainClientExec.establishRoute(AuthState, 
HttpClientConnection, HttpRoute, HttpRequest, HttpClientContext) line: 393     
                        MainClientExec.execute(HttpRoute, HttpRequestWrapper, 
HttpClientContext, HttpExecutionAware) line: 236  
                        ProtocolExec.execute(HttpRoute, HttpRequestWrapper, 
HttpClientContext, HttpExecutionAware) line: 186    
                        RetryExec.execute(HttpRoute, HttpRequestWrapper, 
HttpClientContext, HttpExecutionAware) line: 89        
                        RedirectExec.execute(HttpRoute, HttpRequestWrapper, 
HttpClientContext, HttpExecutionAware) line: 110    
                        InternalHttpClient.doExecute(HttpHost, HttpRequest, 
HttpContext) line: 185      
                        
InternalHttpClient(CloseableHttpClient).execute(HttpUriRequest, HttpContext) 
line: 83   
                        
InternalHttpClient(CloseableHttpClient).execute(HttpUriRequest) line: 108       
                        
InternalHttpClient(CloseableHttpClient).execute(HttpUriRequest) line: 56        
                        HttpClientMain.main(String[]) line: 21  
        /usr/lib/jvm/java-8-oracle/bin/java (22 Jun 2020, 10:28:48 pm)  


> Read timeout not applied for SSLHandshake when using proxy
> ----------------------------------------------------------
>
>                 Key: HTTPCLIENT-2090
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2090
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.12
>            Reporter: Dave Moten
>            Priority: Minor
>
> When I make a connection to an https endpoint without proxy I've confirmed 
> that read timeouts as specified in the RequestConfig part of the client are 
> applied by putting a breakpoint against the startHandshake line in 
> SSLConnectionSocketFactory:394 (I viewed the expression 
> sslsock.getSoTimeout()).
> However, when I make a connection to an https endpoint (e.g. 
> https://google.com) via our corporate proxy I can see via the same breakpoint 
> that sslsock.getSoTimeout() returns 0.
> Here's the test code that when debugged showed the problem:
> {{RequestConfig requestConfig = RequestConfig
>         .custom()
>         .setConnectionRequestTimeout(10000)
>         .setConnectTimeout(10000)
>         .setSocketTimeout(5000)
>         .build();
> HttpClient client = HttpClientBuilder
>         .create()
>         .setDefaultRequestConfig(requestConfig) 
>         .setProxy(HttpHost.create("http://proxy:8080";)) //
>         .build();
> HttpGet get = new HttpGet("https://google.com";);
> client.execute(get);}}
> By the way the consequence of this has been hangs in our production 
> environment talking to Microsoft's EWS service which seemed to be flaky last 
> week.
> I have a workaround described by Li Changshu in HTTPCLIENT-1478 involving 
> setting a pooling connection manager but I would like the library to behave 
> consistently when using a proxy.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to