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

HttpURLConnection Keep-Alive fails for requests that return content-length 0

XMLWordPrintable

    • rc1
    • unknown, x86, sparc
    • generic, solaris_8, windows_2000
    • Verified



      Name: nt126004 Date: 09/26/2001


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


      There is a bug in HttpClient.parseHTTPHeader. For refresh requests that
      return a 304 responce code (and not chunked) from the server, a content-length
      is not sent. However, you guys don't differentiate between responce codes
      and kill the keep-alive if content-length is not present.

      Due to this bug, one can't use these classes on server side, cause you run
      out of sockets very quickly.

      here is the code where the bug exists:
      sun.net.www.http.HttpClient.parseHTTPHeader(..) {
      ....
                  try
                  {
                      l = Integer.parseInt(messageheader.findValue("content-length"));
                  }
                  catch(Exception exception2) { }
                  if(keepAliveConnections > 1 && l > 0)
                      keepingAlive = true;
                  else
                  if(keepingAlive)
                      keepingAlive = false;
      ....
      }

      Run the test program below and examine with netstat -n (on a widnows
      platform). You will see, that if the responce from the server is a 304, two
      sockets will be used instead of one. Comment out the following line in the
      code below to see the program work correctly, using the same socket to fetch
      the second image "urlConnection.setRequestProperty("If-Modified-Since","Thu,
      13 Sep 2001 16:13:01 GMT");"

      netstat -n result when response not 304 but 200:
        TCP 192.168.109.52:2144 66.48.7.21:80 TIME_WAIT

      netstat -n result when response is a 304:
       TCP 192.168.109.52:2145 66.48.7.21:80 TIME_WAIT
       TCP 192.168.109.52:2146 66.48.7.21:80 TIME_WAIT




      Here is the test program:

      import java.net.*;
      import java.io.*;

      public class test implements Runnable {

      public test() {
      }
      public void run(){
      }

      public static void main(String[] args) {
      try { //some server with an image

      doConnection("http://66.48.7.21/images/23.gif");
      Thread.sleep(2000);
      doConnection("http://66.48.7.21/images/23.gif");
      Thread.sleep(3000);

      } catch (Exception e) {
      e.printStackTrace();
      }
      }

      public static void doConnection(String urlString) throws Exception
      {
      URL url = new URL(urlString);
      HttpURLConnection urlConnection = (HttpURLConnection)url.openConnection();


      String inputLine;

      //comment this out to see stats without refresh
      urlConnection.setRequestProperty("If-Modified-Since","Thu, 13 Sep 2001 16:13:01 GMT");

      urlConnection.connect();
      DataInputStream reader = new DataInputStream(urlConnection.getInputStream());
      //if not modified
      if (urlConnection.getResponseCode() != 304) {
      while ((inputLine = reader.readLine()) != null) {
      System.out.println(inputLine);
      }
      }
                    else {
                      System.out.println("No change to image");
                    }
      reader.close();
      }

      }
      (Review ID: 132592)
      ======================================================================

            alanb Alan Bateman
            nthompsosunw Nathanael Thompson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: