※ RFC7230 時点の情報に更新 → HTTP/1.1 のコネクション管理の理解メモ – CAT EARS
HTTPリクエストの処理中(長いAPサーバーの処理等)にタイムアウトなどでTCPコネクションが切断された場合、HTTPクライアントはRFC2616に従い同じリクエストを勝手に再送する事がある。(SHOLDとなっているのでその場合の方が多いかと)
なので、場合によっては二重POSTとなってしまう。。
非冪等メソッドの自動再試行は不可。
これはHTTPベースのプロトコル(SOAPやAMF、WebDAV等のRPC)全てに当てはまるため、RPCを使用する際には注意が必要である。
失敗パターンは リクエスト送信→失敗→再送信→失敗→切断(エラー?) が標準動作。
RFC2616 8.1.4 Practical Considerations より抜粋
A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request
at the same time that the server has decided to close the “idle”
connection. From the server’s point of view, the connection is being
closed while it was idle, but from the client’s point of view, a
request is in progress.This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2). Non-idempotent methods or sequences
MUST NOT be automatically retried, although user agents MAY offer a
human operator the choice of retrying the request(s). Confirmation by
user-agent software with semantic understanding of the application
MAY substitute for user confirmation. The automatic retry SHOULD NOT
be repeated if the second sequence of requests fails.
参考: