JDK-6382788 : URLConnection is silently retrying POST request
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0,5.0u6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_9,windows_xp
  • CPU: x86,sparc
  • Submitted: 2006-02-08
  • Updated: 2020-03-06
  • Resolved: 2006-07-01
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 JDK 6
1.4.2_14Fixed 6 b91Fixed
Related Reports
Duplicate :  
JDK-6427251 - HttpURLConnection automatically retries non-idempotent method POST
Duplicate :  
JDK-6430061 - Sun's HTTP handler retrying requests
Relates :  
JDK-8183369 - RFC unconformity of HttpURLConnection with proxy
Description
Client send a synchronous request. Server sleep for 10 minutes.
When this is the the first request that is sent between the client and the server, the client request is not retried. The client waits the expected amount of time.

If this is a request that comes after the first one, after EXACTLY 5 minutes, the request is retried.

It is not retried in the JAX-WS stack BUT at the HTTP transport level.
The retries is located in sun.net.www.http.HTTPClient.parseHTTPHeader(). 
After 5 minutes, the socket.read returns with a size == 0. Then the request is retried ONLY once.

I am wandering if this is the http stack or JAX-WS usage of it that is wrong.

I attached you a client, a server and a WSDL that show the problem EVERY TIME (at least on solaris).
I also attached a modified HTTPClient in order to trace what is going on.

In the JMX Connector, we are polling for Notifications. The Polling request can be waiting , on the server side, a very long time. We will ran into this issue.
Comments
EVALUATION Non-idempotent http POST requests are being automatically resent to the server if the server does not respond with a valid http response or an IOException occurs. This is incorrect according to the rfc. Only idempotent requests are supposed to be automatically resent. As this has been the behavior of Sun's http client forever, some users may be relying on this behavior without even knowing it. So the solution is to allow this behavior to be configured through a system property, sun.net.http.retryPost. sun.net.http.retryPost determines if the an unsuccessful http POST request will be automatically resent to the server. Unsuccessful in this case means the server did not send a valid http response or an IOException occurred. The default value is true to maintain backward compatibility. This is a Sun implementation specific property that is only related to Sun's http protocol handler.
20-06-2006
EVALUATION re-opening. The non-idempotent method, POST, should not be retried. It currently is.
04-04-2006
EVALUATION HttpURLConnection is behaving in accordance with RFC 2616 (HTTP/1.1) section 8.1.4 "Practical Considerations"
04-04-2006