>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
>For request method other than POST or PUT, 1. set request properties; 2. call
>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
>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.