Can i just write to a URLConnection but don't read?

[Li Shangqiang]

I've know that i can use a URLConnection by 2 ways:
a) just read from it
b) write to it and then read from it
but can i just read from it and don't write to it? I've tried like this:
URL url=new URL("http://localhost:8080/test/servlet/MyServlet");
URLConnection conn=url.openConnection();
conn.setDoOutput(true);
conn.setDoInput(false);
conn.setUseCache(false);
OutputStream out=conn.getOutputStream();
out.write
..
out.close();
on the Servlet side, i code:

doPost(HttpServletRequest request, HttpServletResponse response) throws
{
InputStream in=request.getInputStream();
in.read
..
in.close();
..
}
But when run it, there is error on both side, reporting that "connection reset by peer..". I think it may do something with the HTTP protocol but i'm not familiar with it.

[Carl Trusiak]

Http is a request AND response protocol. The server wants to send some response to the request so... Closing the connection without writing anything to the response will cause the error you see.

[Rahul Rathore]

Li
Here is the cure for your problem:-
Immediately after your statement out.close() add the statement conn.getInputStream(). Do this even though you don't want to read from the input stream. Don't make any other changes. This should work !!
Let us know if it works. I will then give you the reason for it, and I will tell you a beautiful article to read to understand the hidden traps of using URL/URLConnection classes

[This message has been edited by Rahul Rathore (edited April 12, 2001).]

[Li Shangqiang]

Rahul, Successful!
I've done as you said and the connection speed short from about 300 ms to about 50 ms(in IE Applet), I think you have helped me very much. Thank you a lot!
But there are problems yet:
i) if i run it from application, the connection don't read is slower than the connection read something
ii) what's the basic behavior of URLConnection?

[Rahul Rathore]

Read this beautiful Javaworld article explaining the URL/URLConnection classes and the hidden traps:- http://www.javaworld.com/javaworld/jw-03-2001/jw-0323-traps.html
The author says that it is con.getInputStream() which actually posts the request to the server !!
1. When we do con.getOutputStream() and write to the output stream, actually that writing is done to a local buffer- NOT to the server.
2. When we do con.getInputStream()- it is now that what is in the local buffer is posted to the server !!
The author warns of several traps for eg:-
TRAP 1:
--you do con.getInputStream()
--you do con.getOutputStream()
--you write to output stream
Result=Failure: When getInputStream is done nothing has been written to the POST buffer- so nothing is posted - and subsequent opening of output stream throws exception.
TRAP 2:
--you do con.getOutputStream()
--you write to output stream and flush
--you do NOT do con.getInputStream()
Result=Failure: The writing to the output stream merely writes to local buffer. Without getInputStream() nothing is posted to the server.
TRAP 3:
--you do con.getOutputStream()
--you do con.getInputStream() //before writing to output stream
--you write to output stream and flush
Result=Failure: At the time getInputStream is done, nothing has been written to the the local POST buffer. So nothing is posted to the server even though the server/servlet is invoked. Subsequent writing is useless.
SUCCESSFUL METHOD:
--you do con.getOutputStream()
--you write to output stream and flush
--you do con.getInputStream()
Result=Success. This is the order which we must strictly and compulsorily adhere to.