Bug ID: JDK-4192018 URLConnection.getOutputStream() fails after connect()

Versions (Unresolved/Resolved/Fixed)

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.

Other
1.4.0 merlinFixed


Name: jn10789			Date: 11/20/98


This problem arises with Netscape 4.05, Java Plugin 1.1.1, configured to use JRE 1.2, JDK 1.2 beta 4.
It worked with older Versions and Internet Explorer's Java VM.

------------------------------------------------
The following JAVA-Code should expose the problem

---------------------------------
try {
	URL url = new URL("http://web-server/cgi-bin/someProg/someFile");
	URLConnection urlConnection = url.openConnection();
	urlConnection.setDoOutput(true);
	urlConnection.connect();
	OutputStream os = urlConnection.getOutputStream();
}
catch (Exception ex) {
	ex.printStackTrace();
}
------------------------------------

This piece of code produces the following exception:

java.net.ProtocolException: Can't reset method: already connected
 at java.net.HttpURLConnection.setRequestMethod(Compiled Code)
 at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:429)
 at ...
 at java.lang.Thread.run(Thread.java:475)

------------------------------------
When I comment the call connect() out, then no exception is raised, but the connection does not seem to be established. connect() after getOutputStream() has the same effect (besides it doesn't make sense, does it?).

Documentation on java.net.URLConnection says:
The following methods are used to access the header fields and the contents >>>after the connection is made<<< to the
remote object: 

     getContent 
     getHeaderField 
     getInputStream 
     getOutputStream
(Review ID: 37266)
======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic merlin FIXED IN: merlin INTEGRATED IN: merlin

14-06-2004

EVALUATION >For backward compatibility's sake, we can't change the current behaviours with >getOutputStream and getInputStream. Although I don't think that current >behaviour is wrong, I do believe it can be confusing to the users, and thus >warrants better documentation. The calling sequence that you are supposed to >follow is: > >For request method other than POST or PUT, 1. set request properties; 2. call >getInputStream. > >For POST and PUT request methods, 1. set request properties; 2. call >getOutputStream and write to the outputstream; 3. call getInputStream to send >out the request and get the response from server. > >You can not call getOutputStream alone and expect the flush method would cause >the request to be sent to the server. The only way to send out the request is by >calling getInputStream. > >Since by the time you call getOutputStream, no request has yet been sent to the >server, it is safe to change the request method from "GET" to "POST", without >caring that the connection (TCP connection) is already established. > >There is another bug jdn evaluated. 4146690: Opening a URL connection for input >and output. Here's your evaluation: > >It is illegal to call getOutputStream() after calling >getInputStream(). The idea is that you are supposed to call getOutputStream() >to write whatever it is you have to send, flush(), and then call >getInputStream() and read the reply. The HttpURLConnection() cares >about the ordering of this. The call to getInputStream() triggers the >previously written output to actually get sent as an HTTP request. >I know it is a bit strange and is not well documented but that is the >way it works.

11-06-2004

WORK AROUND Name: jn10789 Date: 11/20/98 I have not found one yet. ======================================================================

11-06-2004