HTML応答の400エラーにおけるAPIリクエスト検証
2023年6月5日より 、AmazonではHTTP RFC 7230に準拠していないリクエストが拒否されます。2023年4月25日以降、一部のリクエストにこの制限が適用されています。
HTTP RFC 7230に準拠していないリクエストには、エラー400のステータスコードとHTML応答が返されます。メトリクスとログをチェックして、400ステータスコードとHTML応答が含まれるエラーを受信していないか確認してください。
このエラーが表示されている場合は、以下の手順に従って、クライアントコードの問題を特定し解決してください。このエラーが表示されていない場合、対応の必要はありません。
HTML応答の400エラーのトラブルシューティング
トラブルシューティングのタイミング
リクエストの結果、HTML応答で400ステータスコードのエラーが表示されるときは、以下のトラブルシューティング情報を活用してください。SP-APIからの標準応答は、アプリケーション/JSON形式です。したがって、テキスト/HTML形式の応答は、Selling Partner API（SP-API）がリクエストを処理する前にエラーが発生したことを示しています。
エラー応答の例：
{
HTTP/1.1 400 Bad Request Server:
Server Date: Tue, 16 May 2023 06:02:44 GMT
Content-Type: text/html
Transfer-Encoding: chunked Connection: close
}
トラブルシューティングの方法
400エラーが表示され、標準のSP-APIレスポンスのボディが表示されない場合は、リクエストが拒否される既知の原因を以下のリストからチェックしてください。エラーが起きる最も一般的な原因は、GETリクエストにボディまたはContent-Lengthヘッダーが存在することです。原因を特定したら、クライアントコードで解決します。
RFCに準拠していない、リクエストが拒否される原因となるリクエストのパターン：
- GET/HEADリクエストにボディまたはContent-Lengthヘッダーがある
- ホストヘッダーが重複しているか形式が間違っている
- URIにCTL（コントロール）文字が含まれている
- リクエスト内に空のヘッダー、または空白を含む行がある
- GET/HEADリクエストにTransfer-Encodingヘッダーがある
- Content-Lengthヘッダーが重複している（値が同じ）
- リクエストにTransfer-EncodingとContent-Lengthの両方がある
- RFCに準拠しない複数行ヘッダーがある
- ヘッダー行が終了していない
- リクエストの最後に空白の行がある
- ヘッダー行にコロン区切り文字がない
- リクエストにURIがない
- ヘッダーにヌル文字またはCRが含まれている
- URIにヌル文字またはCRが含まれている
- Content-Lengthヘッダーが異なっている
- Content-Lengthの値が解析可能でないか、数値が無効である
- HTTPメソッドの形式が正しくない
リクエストの検査方法
標準とサードパーティ開発のHTTPクライアントは何百もあり、Amazonでクライアントごとの動作を可視化したり把握したりできないため、送信リクエストの検査方法は1つではありません。
通常は以下のエリアをチェックします。
- SP-APIに送られるHTTPリクエストがいつ作成されたかを特定し、そのリクエストを調べます。
- 送信リクエストのすべてのヘッダーとURIの情報を収集します。ヘッダー情報を取得するプログラム方法を提供しているクライアントもあります。
- HTTPクライアントに、ログ機能があるかどうか、または設定によってログを有効にできるかどうかを確認します。
- オープンソースのHTTPクライアントの場合、コードを表示すると、リクエストがどのように作成されているか、想定に誤りがないかを判断できる可能性があります。
- リクエストを送信する前にアダプターまたはプラグインを使用している場合、アダプターやプラグインでリクエストを変更できます。
- 送信リクエストに関する詳細を提供できる通信ログを有効にできるかどうかを確認します。
- SP-APIを呼び出すために同様のcurlまたはwgetコマンドを作成できて、同じ問題が発生しない場合は、HTTPクライアントの動作に何らかの違いがある可能性があります。
