RFR[15] JDK-8183369 : RFC unconformity of HttpURLConnection with proxy

Chris Hegarty chris.hegarty at oracle.com
Thu Feb 13 09:36:38 UTC 2020


Hi Ravi,

> On 5 Feb 2020, at 12:43, Ravi Reddy <ravi.k.reddy at oracle.com> wrote:
> 
> Hello All,
>  
> Could you please review this patch. This patch fixes the RFC unconformity of HttpURLConnection with proxy issue.
>  
> 1.Change in HttpURLConnection.java is to make sure we do retry with proxy as mentioned in RFC
> 2.Change is test case HttpURLConWithProxy.java is to make sure we don’t throw an error “Can’t use direct connection” even when the connection is made through proxy.
>  
> Webrev: http://cr.openjdk.java.net/~coffeys/webrev.8183369/index.html <http://cr.openjdk.java.net/~coffeys/webrev.8183369/index.html>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8183369 <https://bugs.openjdk.java.net/browse/JDK-8183369>
To better understand the issue and the behavior of the HTTP protocol
handler I had to dig into the history.

Back in JDK 9, the changes for 8161016 [1] altered the behavior of the
failed-proxy-connect case to not retry with a direct connection, but to
instead throw the IOException that occurred during the failed connection
attempt.

What is being proposed now is to reinstate the retry, but instead of
retrying with a direct connection, retry with the same proxy as
previously just failed. Right?

This effectively amounts to the following changes ( over that of what
is in JDK 8 ):

   --- http = getNewHttpClient(url, null, connectTimeout, false);
   +++ http = getNewHttpClient(url, p, connectTimeout, false);

I notice that the `break` from the original code has not been
reintroduced. I don't think that it is strictly needed, but did you give
it any consideration?

-Chris.

[1] 8161016: Strange behavior of URLConnection with proxy
    https://hg.openjdk.java.net/jdk/jdk/rev/9b5eee5d7a26


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200213/4873ff38/attachment.htm>


More information about the net-dev mailing list