Default behaviour of retryOnConnectionFailure is dangerous for POST requests

Default behaviour of OkHttpClient.Builder to set retryOnConnectionFailure may result in POST requests being silently resent on network timeouts.

While this may be typically alright for GET requests, POST/PATCH/DELETE requests modify data, and re-submitting them without knowing whether they have been received at the other end.

[ktchernov]

I have investigated this further, and there is a change in behaviour between v2 and v3 here, which is in the way SocketConnectionTimeout is handled. In v2 the request was always dropped, in v3 the connection is retried unless retryOnConnectionFailure is set.

Compare https://github.com/square/okhttp/blob/parent-3.0.0-RC1/okhttp/src/main/java/okhttp3/internal/http/StreamAllocation.java line 336 to https://github.com/square/okhttp/blob/parent-2.7.5/okhttp/src/main/java/com/squareup/okhttp/internal/http/StreamAllocation.java line 358

This means that if the client sent a POST request, then the server received it but the response got lost due to network issues, the client will resend it again. While in v2 it would fail.

[swankjesse]

I think the nuanced fix we want is to recover from timeouts that occur during connect, but not during read.