JDK-4143518 : Need ability to set socket options on URLConnection
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version:
    1.1.6,1.2.2,1.3.0,1.3.1,1.4.0,1.4.0_01,1.4.1 1.1.6,1.2.2,1.3.0,1.3.1,1.4.0,1.4.0_01,1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    generic,linux,solaris_2.6,windows_98,windows_nt,windows_2000 generic,linux,solaris_2.6,windows_98,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 1998-05-28
  • Updated: 2003-10-08
  • Resolved: 2003-10-08
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Description

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)
======================================================================

Comments
EVALUATION The URLConnection api normally abstracts away the socket and raw HTTP connection and instead models single request/reply transactions. The only way I can forsee allowing application code to access or manipulate socket level issues is in the context of allowing a custom socket factory to be set on a protocol-specific subclass of URLConnection such as HttpURLConnection. In that case, persistent HTTP connections, pipelining and the like would only be shared across HttpURLConnection instances that passed in a common socket factory instance. This request will be considered in the broader context of exposing a socket factory construct. jeff.nisewanger@Eng 1998-10-30 One possibility is through the use of SocketFactory, like what JSSE did in its HttpURLHandler. yingxian.wang@eng 2000-02-08 ==================================================================== Independent of the outcome of this rfe, the following may be useful. A system property "http.defaultSocketTimeout" is being defined for 1.4 which will define a maximum number of milli-seconds to wait in a blocking read in HTTP connections. A SocketTimeoutException will be thrown if the timeout is reached. michael.mcmahon@ireland 2001-02-02 =================================================================== Developers tracking this RFE should check-out 4700777 as tiger (1.5) has introduced new setReadTimeout and setConnectTimeout methods to java.net.URLConnection so that applications can specify the read and connect timeouts. For 1.4.x the workaround is to use the sun.net.client.defaultReadTimeout and sun.net.client.defaultConnectTimeout system properties. These system properties are specific to the Sun provided protocol handlers and aren't a general/API solution. However they are useful workaround until tiger is released.
11-06-2004