United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4192018 URLConnection.getOutputStream() fails after connect()
4192018 : URLConnection.getOutputStream() fails after connect()

Details
Type:
Bug
Submit Date:
1998-11-21
Status:
Resolved
Updated Date:
2000-09-08
Project Name:
JDK
Resolved Date:
2000-09-08
Component:
core-libs
OS:
windows_nt
Sub-Component:
java.net
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.2.0
Fixed Versions:
1.4.0

Related Reports

Sub Tasks

Description

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

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
generic
merlin

FIXED IN:
merlin

INTEGRATED IN:
merlin
2004-06-14 
WORK AROUND



Name: jn10789			Date: 11/20/98


I have not found one yet.
======================================================================
2004-06-11 
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.
2004-06-11


Hardware and Software, Engineered to Work Together