HTTP 409 Conflictとは？意味と解決方法

このエラーの意味と見分け方

• ブラウザ、APIクライアント、監視ツール、インテグレーションがHTTP 409 Conflictレスポンスを受け取る。
• リソースの作成または更新に失敗する一方で、他のページやAPIルートは引き続き動作する。
• POST、PUT、PATCHなど、特定のHTTPメソッドでのみエラーが発生することがある。
• 同じリクエストを繰り返すと同じ競合が発生する一方、別のリソースへのリクエストは成功する。
• レスポンスボディに、既存リソース、古いバージョン、重複値、状態遷移、アプリケーションのルールなどが示されることがある。
• DNSが名前解決でき、TLSも成功している場合があります。これはリクエストがHTTP対応エンドポイントに到達したことを示すだけであり、別の確認項目です。

可能性の高い順の主な原因

1. リソースがすでに存在する、または一意の値が重複している。 作成処理で、既存のレコード、ユーザー名、識別子、ファイル名など、一意性が制約された値と競合することがあります。
2. 同時更新または古い状態での更新。 クライアントが最後に読み取ってからリソースが変更され、送信したバージョンが現在の状態と一致しなくなっている可能性があります。
3. 無効な状態遷移。 アプリケーションが、リソースの現在の状態では許可されない操作を拒否することがあります。たとえば、完了済み、アーカイブ済み、ロック済みの項目を変更する場合などです。
4. アプリケーションまたはWebサーバーのルール。 ルートのロジック、バリデーション、リクエストポリシー、カスタムエラーハンドリングによって、既知の競合に対して意図的に409を返すことがあります。
5. プロキシ、CDN、WAFの動作。 ルーティング、キャッシュ、リクエスト検査、上流設定などにより、中間装置がレスポンスを生成または変換することがあります。
6. 環境固有の認証または認可ルール。 アプリケーションによっては、アカウントやリソースの状態に関する競合に409を使用します。ただし、認証エラーには通常、別のステータスコードが使われます。ステータスコードの出所を推測せず、レスポンスとログで動作を確認してください。

修正方法

まずリクエストを確認する

1. 正確なURL、HTTPメソッド、リクエストボディ、認証済みユーザーまたはクライアントのコンテキスト、発生時刻、最終ステータスコードを記録します。
2. レスポンスヘッダーとボディを確認し、競合識別子、リソースの場所、バージョン情報、キャッシュ状態、プロキシの識別情報、アプリケーションのエラーメッセージを探します。
3. リダイレクトが発生したか、409が最終エンドポイントから返されたのか中間装置から返されたのかを確認します。
4. そのルートとメソッドに対して意図されたレスポンスかどうかが分かるまで、設定を変更しないでください。

サイト訪問者またはAPI利用者の場合

1. URL、選択したアカウントまたはリソース、送信したデータを確認します。
2. リソースを作成する操作なら、再送信する前にそのリソースがすでに存在していないか確認します。
3. リソースを更新する操作なら、現在のバージョンを再取得または更新して、アプリケーションがサポートする更新手順でのみ再試行します。
4. 認証が必要なリソースの場合は、通常のアカウントログイン手順でサインインします。信頼できないページにパスワードやトークンを送信しないでください。
5. レスポンスが重複、ロック状態、サーバー側の制限を示している場合、再試行を繰り返さないでください。
6. 競合が解消しない場合は、エンドポイント、メソッド、タイムスタンプ、レスポンスボディ、サニタイズしたリクエスト識別子をサイト所有者またはAPIプロバイダーに送ります。パスワード、Cookie、APIキー、個人データは削除してください。

WebサイトまたはAPIの管理者の場合

1. 同じメソッド、URL、リクエストデータ、アカウントまたはクライアントのコンテキストで問題を再現します。データを変更する操作では、テスト環境またはステージング環境を使用してください。
2. レスポンスを生成したコンポーネント（アプリケーション、Webサーバー、リバースプロキシ、CDN、WAF）を特定します。利用可能であれば、レスポンスヘッダー、サーバーシグネチャ、リクエスト識別子を比較します。
3. 該当するコンポーネントのログを検索し、タイムスタンプ、ルート、メソッド、ユーザーまたはクライアント識別子、上流レスポンスを関連付けます。
4. 作成処理では、重複や一意フィールドの制約を確認します。更新処理では、アプリケーションが使用する楽観的ロック、バージョン、ETag、その他の同時実行制御データを確認します。
5. リソースの現在の状態と、アプリケーションで許可されている状態遷移を確認します。許可と影響を理解しないまま、削除や上書きだけで競合を回避しないでください。
6. 最近のデプロイと、ルーティング、バリデーション、認証、キャッシュ、プロキシ、WAFルールへの変更を比較します。
7. 文書化された中で最も範囲の狭い修正を適用し、同じリクエストと関連ルートへの通常のリクエストを再テストします。レスポンスボディ、ヘッダー、ステータスコードが意図した動作と一致することを確認します。
8. 409が意図的なものであれば、競合の内容を説明し、必要に応じてクライアントが状態を更新する方法、別の値を選ぶ方法、状態を解決する方法を示して、対応可能なレスポンスにします。

予防と修正確認

• どの操作が意図的に409を返す可能性があるか、またクライアントが次に何をすべきかを文書化します。
• APIレスポンスには、重複、古いバージョン、無効な状態を明確に示すメッセージを使用します。
• アプリケーションのリリース後に、作成、更新、同時更新のワークフローをテストします。
• ルーティング、プロキシ、認証、キャッシュ、WAFの設定をバージョン管理します。
• すべての409レスポンスを一つの問題として扱わず、ルートとHTTPメソッド別にステータスコードを監視します。
• 競合をデプロイや設定変更と関連付けられるよう、アプリケーションとインフラのログを十分な期間保持します。
• アプリケーションがサポートするバージョン方式や条件付き更新メカニズムなど、文書化された同時実行制御戦略を使用します。

よくある質問