Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8161016

Strange behavior of URLConnection with proxy

    Details

    • Subcomponent:
    • Resolved In Build:
      b135
    • Verification:
      Verified

      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?

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                rpatil Ramanand Patil (Inactive)
                Reporter:
                shadowbug Shadow Bug
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: