HTTP 501 Not Implemented：意味と修正方法

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

• ブラウザー、API クライアント、監視サービス、または HTTP チェッカーが 501 Not Implemented を受信する。
• レスポンスは、1 つの URL、HTTP メソッド、プロトコル機能、またはリクエスト形式に対してのみ発生する場合がある。
• 他のページや API エンドポイントは通常どおり動作し続けることがある。
• レスポンスヘッダーにサーバーや中間コンポーネントが示され、キャッシュ、認証、リダイレクト、プロキシに関する状況が含まれる場合がある。
• HTTPS リクエストで HTTP 501 を受信した場合、そのリクエストに必要な接続層の処理を終えた後、HTTP を処理するエンドポイントにリクエストが到達したことを意味します。DNS、TLS、ネットワーク経路のすべてが正常であることを証明するものではありません。

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

考えられる原因（具体的なものから、頻度の低いものへ）

1. 要求された HTTP 機能がサポートされていない。 サーバーまたはアプリケーションが、要求されたメソッド、プロトコル動作、リクエスト機能、またはルート機能を実装していない可能性があります。
2. ルートまたはメソッドが、サポートされていないハンドラーに割り当てられている。 たとえば、デプロイによってパスは公開されていても、そのリクエストを処理する想定のアプリケーションロジックに接続されていない場合があります。
3. リバースプロキシ、CDN、WAF、またはゲートウェイがレスポンスを生成している。 中間コンポーネントが、アプリケーションに到達する前にリクエストを拒否または処理不能として返すことがあります。
4. 設定またはデプロイの変更によって、リクエスト処理が変わった。 ルーティング、プロキシ、サーバー、またはアプリケーションの変更により、以前はサポートされていたリクエストが利用できなくなることがあります。
5. リクエストがエンドポイントのサポート対象の仕様に一致していない。 特殊なメソッド、プロトコルの詳細、Content-Type、またはリクエスト形式によって、未サポートのコードパスが明らかになる場合があります。すべてのリクエスト不一致を 501 と判断するのではなく、ドキュメントに記載されたエンドポイントの動作を確認してください。

認証失敗、認可失敗、レート制限、不正な形式のリクエストには、通常、別のステータスコードが使われます。501 の原因と判断する前に、完全なレスポンスとログを確認してください。

修正方法

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

1. 正確な URL を一度再試行し、アドレス、パス、クエリパラメーター、リクエストメソッドが正しいことを確認します。
2. エンドポイントで通常アカウントが必要な場合は、サイトの通常の手順でサインインしてから再試行します。見慣れないエンドポイントに認証情報を送信しないでください。
3. API クライアントを使用している場合は、メソッドとリクエスト形式をエンドポイントのドキュメントと比較します。ブラウザーでのアクセスには GET が使われる一方、API 操作では別のメソッドが必要な場合があります。
4. レスポンスヘッダーと本文を確認し、サーバー、プロキシ、認証、リダイレクト、キャッシュに関する手がかりを探します。診断情報を共有する際は、Cookie、Authorization ヘッダー、API キー、その他の秘密情報を公開しないでください。
5. サービスが失敗している、または制限を示している場合は、繰り返し再試行しないでください。URL、メソッド、おおよその時刻、レスポンスステータス、関連ヘッダーのサニタイズ済みコピーを記録します。
6. エラーが続く場合は、その情報をサイトまたは API の所有者に送ります。サーバー側の未サポート機能を修正できるのは、レスポンスを返したサービスの運用者だけです。

ウェブサイトまたは API の所有者の場合

1. 失敗したリクエストを正確に取得します。 HTTP メソッド、URL、クエリパラメーター、ルーティングに関係するリクエストヘッダー、ステータス、レスポンスヘッダー、サニタイズ済みのレスポンス本文を記録します。成功するリクエストと比較してください。
2. その動作が意図されたものか判断します。 ルートとメソッドがサポート対象か確認します。メソッドが未実装ではなく禁止されている場合、意図されたレスポンスは 405 など別のステータスになる可能性があります。ステータスコードを変更する際は、サービスの実際の仕様と実装を根拠にしてください。
3. レスポンスを生成した層を特定します。 501 がアプリケーション、Web サーバー、リバースプロキシ、CDN、WAF、API ゲートウェイ、または別の中間コンポーネントのどれから返されたかを確認します。ヘッダーだけでは推測にとどまる場合があるため、タイムスタンプ付きのログで裏付けてください。
4. 一致するログを調べます。 関係する各層で、同じリクエスト時刻、ルート、メソッド、リクエスト ID、アップストリームの結果を検索します。最も外側のコンポーネントから開始し、アプリケーションに向かってリクエストを追跡します。
5. 最近の変更を確認します。 ルーティング、サーバーモジュール、プロキシルール、API ハンドラー、CDN の動作、WAF ポリシー、プロトコル設定に対するデプロイと変更を比較します。失敗しているルートまたはメソッドに影響する変更に注目してください。
6. 最小限の安全なリクエストで再現します。 問題を発生させるために必要なメソッドとルートは維持しながら、不要なヘッダーとペイロード項目を削除します。可能であれば、まず承認済みの非本番環境でテストしてください。
7. 最も限定的な修正を適用します。 想定されるハンドラーを復元するか、対象のルートまたは中間コンポーネントのルールを調整します。ログによって直接の原因であることが示され、変更が承認されている場合を除き、広範なセキュリティ、認証、権限、プロキシの変更は避けてください。
8. 元のリクエストと周辺の動作を再テストします。 失敗したリクエストについて、想定されるステータス、レスポンス本文、ヘッダーを確認し、その後、関連するルートとメソッドをテストして、修正によってより広範な問題が発生していないことを確認します。
9. 意図的な動作を文書化します。 未サポート機能に対する 501 が想定どおりの場合は、サポート対象のメソッドとクライアント向けの動作を記録し、監視システムやユーザーが原因不明の障害と誤認しないようにします。

予防と修正確認

• 全体の可用性だけでなく、ルート、メソッド、デプロイごとの HTTP ステータス発生率を監視します。
• アプリケーションのルーティング、Web サーバー、プロキシ、CDN、WAF、ゲートウェイの設定をバージョン管理します。
• リリース後や中間コンポーネントの設定変更後に、サポート対象の HTTP メソッドと重要な API ルートをテストします。
• 意図的にサポートしていないルートとメソッド、およびクライアント向けに想定されるレスポンスを文書化します。
• レスポンスと、それを生成した層を照合できるよう、関連付けられたログとリクエスト ID を十分な期間保持します。
• 単なる汎用ホームページへのリクエストではなく、重要なクライアントが必要とする実際のルートとメソッドを実行するヘルスチェックを使用します。

よくある質問