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

Need ability to set socket options on URLConnection

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 1.1.6, 1.2.2, 1.3.0, 1.3.1, 1.4.0, 1.4.0_01, 1.4.1
    • core-libs
    • generic, x86
    • generic, linux, solaris_2.6, windows_98, windows_nt, windows_2000



      Name: diC59631 Date: 05/28/98


      Enhancement request. Need ability to set
      socket options on URLConnection class or a way
      to get the underlying socket. Most useful for
      long lived http connections which are needed to
      get through most firewalls. Socket Timeout is
      the one I need most.
      (Review ID: 32523)
      ======================================================================

      Name: tb29552 Date: 03/24/2000


      java version "1.3.0rc1"


      I would like to use URLConnection to allow my applet to communicate
      efficiently with my servlet server. In order to get around firewalls and to use
      the browser's SSL encryption mechanisms, I am using standard HTTPS "request"
      type communications. However, for efficiency's sake, I'd like the connection to
      remain open with a Keep-Alive connection. The trouble is that there is no way
      that I can see in the JDK to dynamically set the client's KeepAlive timeout
      setting. I'd like to be able to set it for say, 5 minutes. Unfortunately, the
      timeout setting seems to be implementation dependent, and the Java 1.3RC1
      plug-in seems to have a very short Keep-Alive setting (< 5 seconds). If there
      were a way in URLConnection or in another class to set the system's Keep-Alive
      setting, it would be very helpful.
      (Review ID: 102814)
      ======================================================================

      Name: tb29552 Date: 05/01/2000



      Under "Evaluation" for this feature request, 4143518, the
      comment is that the feature could be implemented in some
      sort of SocketFactory mechnism like the way JSSE implemented
      it. I want to add that whatever mechanism you all create
      to implement this feature, please make sure it can work in an
      untrusted applet. There are many many applications for applets
      that are able to have a constant KeepAlive connection back
      to the originating web server, but it would be a disservice if
      we are forced to have our typically technophobic users enter
      into the frightening world of certificates and keystores.

      (Review ID: 102814)
      ======================================================================

      Name: skT45625 Date: 07/27/2000


      java version "1.3.0"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
      Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

      When using a URLConnection object against a web server that sends back
      'keep-alive' in the HTTP header for the Connection field, the client closes
      the underlying socket 5 seconds after the response has been recieved.

      All the objects that were used in the initial request/response are still in
      scope (i.e. this is not a side effect due to the GC doing its job).

      I changed the Connection field value in the response to 'close' and the
      connection was closed immediately (as it should be). However, when I use 'keep-
      alive', the connection does stay open for a short period, but is closed 5
      seconds after the response has been recieved. As a result, I can't reuse that
      connection.

      // CODE
      public void run() {
      try {
      URL url = new URL("http://localhost");
      URLConnection connection = null;
      BufferedWriter writer = null;
      BufferedReader reader = null;
      String line = null;

      // LOGIN
      connection = url.openConnection();
      connection.setDoOutput(true);
      connection.setDoInput(true);
      connection.setUseCaches(false);
      connection.setRequestProperty("Content-
      Type", "text/xml");

      System.out.println("CLASS: " + (connection.getClass()).getName());

      writer = new BufferedWriter(
      new OutputStreamWriter
      (connection.getOutputStream()));
      System.out.println("SENDING:\n" + logindoc);
      writer.write(logindoc, 0, logindoc.length());
      writer.close();

      System.out.println("CONNECTION: " + connection.getHeaderField("Connection"));
      reader = new BufferedReader(
      new InputStreamReader(connection.getInputStream
      ()));
      System.out.println("\nRECIEVED:");
      while((line = reader.readLine()) != null) {
      System.out.println(line);
      }
      reader.close();
      // Its during the following sleep that the server side gets a null on the
      // socket indicating the client is issuing an EOF.
      try { sleep(6000); }
      catch(InterruptedException e) {}
      // PUBLISH
      connection = url.openConnection();
      connection.setDoOutput(true);
      connection.setDoInput(true);
      connection.setUseCaches(false);
      connection.setRequestProperty("Content-
      Type", "text/xml");

      writer = new BufferedWriter(
      new OutputStreamWriter
      (connection.getOutputStream()));
      System.out.println("SENDING:\n" + pubdoc);
      writer.write(pubdoc, 0, pubdoc.length());
      writer.close();

      reader = new BufferedReader(
      new InputStreamReader(connection.getInputStream
      ()));
      System.out.println("\nRECIEVED:");
      while((line = reader.readLine()) != null) {
      System.out.println(line);
      }
      reader.close();
      (Review ID: 107635)
      ======================================================================

      Name: nt126004 Date: 11/12/2001


      java version "1.3.1_01"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
      Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

      There doesn't seem to be any facility for timing out an HttpURLConnection. You
      should be able to specify the number of milliseconds that you are willing to
      wait for the connection to be established, before taking an alternate course of
      processing (likely through catching an exception).
      (Review ID: 135189)
      ======================================================================

            jccollet Jean-Christophe Collet (Inactive)
            dindrigo Daniel Indrigo (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: