HTTP 415 Unsupported Media Type：意味と解決方法

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

• API クライアント、ブラウザフォーム、アップロードツール、監視チェック、アプリケーションが 415 Unsupported Media Type を報告する。
• 他のページやルートが動作していても、特定のエンドポイント、HTTP メソッド、リクエスト形式だけにレスポンスの影響が及ぶ場合がある。
• ボディ形式、Content-Type、コンテンツエンコーディング、アップロード形式、クライアントライブラリを変更した後にリクエストが失敗することがある。
• レスポンスヘッダーから、レスポンスを生成したサーバー、プロキシ、CDN のほか、キャッシュ、認証、リダイレクト、レート制限に関する状況が分かる場合がある。
• HTTP レスポンスを受信しているため DNS 名前解決と TLS ネゴシエーションが成功している場合がある。ただし、これらの確認だけではリクエストコンテンツが受け入れられたことは証明できない。

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

1. サポートされていないリクエストメディアタイプ： エンドポイントが Content-Type で送信された値を受け付けない。たとえば、JSON のみを受け付けるルートにフォームデータを送信している場合。
2. リクエストヘッダーの誤りまたは欠落： クライアントが Content-Type を省略している、タイプミスした値を送信している、または実際の形式と異なる形式としてボディを指定している。
3. サポートされていないコンテンツエンコーディング： 受信側のコンポーネントが処理できない圧縮方式または転送エンコーディングをリクエストで使用している。
4. エンドポイントまたはメソッドの誤り： 別の表現形式、アップロード形式、HTTP メソッドを想定するルートにリクエストを送信している。
5. プロキシ、CDN、WAF、Webサーバーによる検証： アプリケーションに到達する前に中間コンポーネントがリクエストを拒否している、またはアプリケーションの文書化された要件とは異なるルールを適用している。
6. 最近のアプリケーションまたは設定変更： デプロイ、ルーティング変更、パーサーの更新、認証連携、プロキシルールによって、受け付けられるリクエスト形式が変わっている。

ステータスコードだけでは、原因となったコンポーネントを特定できません。認証、権限、制限、上流設定が原因だと判断する前に、リクエストの詳細と対応するログを確認してください。

修正方法

訪問者・技術に詳しくないユーザー向け

1. 同じ操作を一度だけ再試行する。 URL と、該当する場合は選択したアップロードまたはフォームの操作内容を確認してください。同じリクエストを何度も送信することは避けてください。
2. 通常のサインイン手順を使用する。 エンドポイントにアカウントが必要な場合は、リクエストヘッダーや Cookie を手動で変更せず、サイトの通常のインターフェースからサインインしてください。
3. 送信したファイルまたはコンテンツを確認する。 アップロードまたはフォーム送信中にエラーが発生した場合は、サイトが指定する形式を使用してください。変換せずにファイル名の拡張子だけを変更することは避けてください。
4. サイトがサポートするインターフェースを試す。 API ツール、ブラウザ拡張機能、カスタム連携が失敗する場合は、サイトの通常のWebフォームまたはアプリケーションと比較してください。
5. 解決しない場合はサイト所有者に連絡する。 影響を受けた URL または機能、おおよその時刻、HTTP 415 の結果、失敗した操作を伝えてください。パスワード、Cookie、認証トークン、非公開ファイルの内容は送信しないでください。

開発者・API クライアント向け

1. リクエスト全体の構造を記録する。 メソッド、URL パス、クエリパラメーター、Content-Type、コンテンツエンコーディング、関連する Accept の値、ボディのサニタイズ済みの説明を記録します。秘密情報や個人データを不必要にログへ出力しないでください。
2. リクエストをエンドポイントの契約と比較する。 ルートとメソッドが、送信する表現形式を受け付けることを確認します。たとえば、エンドポイントが JSON、フォームエンコードデータ、multipart フォームデータ、XML、特定のアップロード形式のどれを想定しているかを確認してください。
3. 指定とボディを一致させる。 フォームデータを JSON として指定したり、対応するエンコーディングなしで圧縮ボディを送信したりしないでください。クライアントライブラリに multipart の境界を生成する機能がある場合は、それを使用してください。
4. 最小限の再現ケースを作る。 可能な範囲でオプション項目や関係のないミドルウェアを取り除き、サポートされている既知のボディで同じリクエストを繰り返します。比較できるよう元のリクエストは保持してください。
5. レスポンスを調査する。 ステータス、Content-Type、キャッシュに関する指標、サーバーまたはプロキシの識別情報、リダイレクト、エラーボディを確認します。ゲートウェイが生成したレスポンスは、アプリケーション独自の検証結果を反映していない場合があります。
6. 該当するレイヤーのログを確認する。 リクエストのタイムスタンプ、ルート、相関 ID またはリクエスト ID を、アプリケーション、Webサーバー、リバースプロキシ、CDN、WAF のログと照合します。
7. 最も範囲の狭い修正を適用する。 クライアントヘッダー、シリアライザー、アップロード形式、ルートの契約、または範囲を限定した中間コンポーネントのルールを修正します。最初の対応として、検証、認証、セキュリティフィルタリングを広範囲に無効化しないでください。
8. 再テストし、関連する動作を確認する。 元のリクエストを繰り返した後、同じエンドポイントでサポートされている形式をテストし、関連ルートが意図したステータスコードを返すことを確認します。

サイト所有者・運用担当者向け

1. 同じクライアント種別とリクエストメソッドで障害を再現し、サニタイズ済みのヘッダーとタイミングを記録します。
2. 各レイヤーのレスポンスヘッダーとログを比較し、415 がアプリケーション、Webサーバー、リバースプロキシ、CDN、WAF のどれによって生成されたかを特定します。
3. 最近のデプロイと、ルーティング、リクエスト解析、アップロード処理、プロキシ転送、コンテンツエンコーディング、セキュリティルールへの変更を確認します。
4. キャッシュや中間コンポーネントが、そのリクエストに不適切な保存済みレスポンスを返していないことを確認します。
5. 特定のルートまたはクライアント契約を修正し、受け付ける形式を文書化して、修正を確認できる十分なログを保持します。
6. リクエストが意図的にサポート対象外である場合は、エンドポイントの動作とクライアント向けドキュメントで受け付ける形式が明確になっていることを確認します。

予防と修正確認

• 重要な各エンドポイントで受け付ける HTTP メソッド、メディアタイプ、エンコーディング、アップロード形式を文書化する。
• アプリケーションまたはプロキシを変更した後、代表的な JSON、フォーム、multipart、その他のサポート対象リクエスト形式を自動テストする。
• ルーティング、リクエスト解析、プロキシ、CDN、WAF の設定を、レビュー可能な変更履歴とともにバージョン管理する。
• すべての 4xx レスポンスを一括りにせず、ルートとメソッドごとにステータスコードを監視する。
• 適切にサニタイズしたアプリケーションおよび中間コンポーネントのログと相関 ID を、必要な保持期間にわたって利用できるようにする。
• サーバーが受け付けるメディアタイプの変更時にクライアント連携が明確に失敗するようにし、文書化された契約に対してテストする。

よくある質問