JDK-8161016 : Strange behavior of URLConnection with proxy
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-07-07
  • Updated: 2021-09-09
  • Resolved: 2016-09-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9 Other
7u321Fixed 8u311Fixed 9 b135Fixed openjdk7uFixed
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8164200 :  
JDK-8268881 :  
Description
The customer found the strange behavior of URLConnection when using with a 
proxy.

The following program wants to use a proxy host 1.1.1.1 and port 1111,
and never wants to use a direct connection.

==============================================================
import java.net.*;
class Proxy {
  public static void main(String ... arg) throws Exception {
    System.setProperty("http.proxyHost", "1.1.1.1");
    System.setProperty("http.proxyPort", "1111");
    URL url = new URL("http://2.2.2.2/");
    URLConnection con = url.openConnection();
    int len = con.getContentLength();
    System.out.println(len);
  }
}
==============================================================

The actual behavior, however, is to use proxy 1.1.1.1:1111 firstly, and
after that, it tries to use direct connection for 2.2.2.2:80.

The following tcpdump output shows this behavior.

============================================================== 
# tcpdump -n port 80 or port 1111
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:47:18.597895 IP 10.124.48.19.55790 > 1.1.1.1.1111: Flags [S], seq 
66943025, win 5840, options [mss 1460,sackOK,TS val 653011986 ecr 
0,nop,wscale 6], length 0
15:47:21.593795 IP 10.124.48.19.55790 > 1.1.1.1.1111: Flags [S], seq 
66943025, win 5840, options [mss 1460,sackOK,TS val 653012736 ecr 
0,nop,wscale 6], length 0
15:47:27.593792 IP 10.124.48.19.55790 > 1.1.1.1.1111: Flags [S], seq 
66943025, win 5840, options [mss 1460,sackOK,TS val 653014236 ecr 
0,nop,wscale 6], length 0
15:47:39.597825 IP 10.124.48.19.35116 > 2.2.2.2.80: Flags [S], seq 391094195, 
win 5840, options [mss 1460,sackOK,TS val 653017236 ecr 0,nop,wscale 6], 
length 0
15:47:42.593791 IP 10.124.48.19.35116 > 2.2.2.2.80: Flags [S], seq 391094195, 
win 5840, options [mss 1460,sackOK,TS val 653017986 ecr 0,nop,wscale 6], 
length 0
15:47:48.593797 IP 10.124.48.19.35116 > 2.2.2.2.80: Flags [S], seq 391094195, 
win 5840, options [mss 1460,sackOK,TS val 653019486 ecr 0,nop,wscale 6], 
length 0
==============================================================

It seems that HttpURLConnection intentionally makes direct connection as 
fallback.

==============================================================
sun/net/www/protocol/http/HttpURLConnection.java
   1044 protected void plainConnect0() throws IOException {

   1074 try {
   1075 /* Try to open connections using the following scheme,
   1076 * return on the first one that's successful:
   1077 * 1) if (instProxy != null)
   1078 * connect to instProxy; raise exception if failed
   1079 * 2) else use system default ProxySelector
   1080 * 3) is 2) fails, make direct connection
   1081 */ 
   ==============================================================
Why HttpURLConnection makes direct connection as the fallback of proxy 
connections?

For example, most of browsers never use direct connections when setting the 
proxy.
HttpURLConnection's behavior is not acceptable for those who expect
the same behavior as the normal browsers.
Any RFC or specifications defined by W3C regarding this behavior? 


Comments
Minor note: in jdk9, this change broke a different test: https://bugs.openjdk.java.net/browse/JDK-8166359 however I can't reproduce that in jdk8u.
08-07-2021

Fix Request [8u] I would like to backport this patch to 8u for parity with Oracle 8u311. After unshuffling, the patch applies cleanly to 8u, which then builds fine and the included test passes. The test fails on an unpatched 8u. Thanks
08-07-2021

URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3dc9d5deab5d User: lana Date: 2016-09-07 20:26:15 +0000
07-09-2016

URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3dc9d5deab5d User: robm Date: 2016-09-02 15:49:12 +0000
02-09-2016

On initial inspection, the suggestion seems reasonable. Since this was addressed with JDK-4646885, is this a regression?
25-07-2016