500 サーバーエラー - BadPath

現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報

内容

クライアント アプリケーションが、API 呼び出しのレスポンスとして、HTTP ステータス コード 500 Internal Server Error とエラーコード protocol.http.BadPath を受け取ります。

エラー メッセージ

クライアント アプリケーションが次のレスポンス コードを受け取ります。

HTTP/1.1 500 Internal Server Error

また、次のエラー メッセージが表示される場合があります。

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

考えられる原因

このエラーは、フロー変数 target.url で表されるバックエンド サーバーのリクエスト URL に、スラッシュ（/）ではなく疑問符（?）で始まる path が含まれ、これは無効の場合に発生します。

RFC 3986 のセクション 3: 構文コンポーネントと RFC 3986 のセクション 3.3: パスの仕様に従って、次のようになります。

1. URI 構文 には次のコンポーネントがあります。

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. path コンポーネントは必須で、先頭はスラッシュ（/）でなければならず、常にスラッシュを付けなければなりません。

したがって、バックエンド サーバーのリクエスト URL に、スラッシュ（/）ではなく疑問符（?）で始まる path コンポーネントがある場合、Apigee Edge は 500 Internal Server Error とエラーコード protocol.http.BadPath を返します。

たとえば、target.url の値が https://www.mocktarget.apigee.net?json の場合、path がスラッシュ（/）ではなく疑問符（?）で始まっているため、path が無効であることが判明すると、このエラーが発生します。

原因	説明	トラブルシューティングの実施対象
バックエンド サーバーの URL（target.url）のパスが無効です	フロー変数 target.url で表されるバックエンド サーバー URL のパス コンポーネントは、スラッシュ（/）ではなく疑問符（?）で始まります。	Edge Public Cloud ユーザーと Private Cloud ユーザー

共通の診断手順

このエラーを診断するには、次のいずれかのツールや手法を使用します。

原因: バックエンド サーバーの URL（target.url）のパスが無効です

診断

1. 一般的な診断手順で説明されているように、API Monitoring、Trace ツール、または NGINX アクセスログを使用して、500 Internal Server Error の障害コードと障害ソースを特定します。
2. 障害コードが protocol.http.BadPath で、障害ソースの値が target の場合、バックエンド サーバーの URL に無効なパスがあることを示します。

3. バックエンド サーバーの URL は、Apigee Edge のフロー変数 target.url で表されます。このエラーは通常、ターゲット リクエスト フロー内のポリシー（プロキシ/共有フロー内）のいずれかを使用して、バックエンド サーバーの URL（target.url）を動的に更新しようとした（無効なパスを含む）場合に発生します。

4. 次のいずれかの方法で、フロー変数 target.url に実際に無効な パスがあり、その値のソースがあるかどうかを確認します。

   Trace

   Trace ツールの使用

   このエラーのトレースをキャプチャしている場合は、Trace ツールの使用 で説明されている手順を実施します。

   1. target.url に無効なパスが含まれているかどうか、スラッシュ（/）ではなく疑問符（?）で始まっていないかどうかを確認します。

   2. 含まれている場合は、無効なパスが含まれるように target.url の値を変更または更新したポリシーを特定します。

      JavaScript ポリシーがフロー変数 target.url を更新したことを示すトレースの例

      
   3. 上記のサンプル トレースでは、JavaScript ポリシーによって target.url の値が変更または更新され、無効なパスが含まれていることがわかります。
   4. target.url には次のコンポーネントがあります。
      • スキーム: https
      • authority: mocktarget.apigee.net
      • パス: ?json

      パスはスラッシュ（/）ではなく疑問符（?）で始まるため、無効です。

   ログ

   ログサーバーでのログの使用

   1. このエラー（断続的に発生する問題）のトレースがない場合は、 MessageLogging や ServiceCallout ポリシーなどのポリシーを使用して、フロー変数 target.url の値に関する情報をログサーバーに記録しているかどうかを確認します。
   2. ログがある場合は、それを確認し、
      1. target.url に無効なパスがあるかどうかを確認する
      2. 無効なパスを含むように target.url を変更したポリシーに関する情報を特定できるかどうかを確認します

   API プロキシ

   失敗した API プロキシの確認

   このエラーのトレースやログがない場合は、失敗した API プロキシを確認して、無効なパスを含むためにフロー変数 target.url を変更または更新した原因を特定します。次の点を確認します。

   • API プロキシ内のポリシー
   • プロキシから呼び出されるすべての共有フロー

5. フロー変数 target.url を変更または更新する特定のポリシー（AssignMessage や JavaScript など）を注意深く調べ、無効なパスが含まれるように target.url を更新した原因を特定します。

   以下に、フロー変数 target.url を誤って更新し、このエラーの原因となる無効なパスが含まれるポリシーの例を示します。

   サンプル 1

   サンプル #1: JavaScript ポリシーで target.url 変数を更新する

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);
   

   上記のサンプルでは、フロー変数 target.url が、別の変数 url. に含まれる値 https://mocktarget.apigee.net?json で更新されています。

   url の値には次のコンポーネントが含まれます。

   • スキーム: https
   • authority: mocktarget.apigee.net
   • パス: ?json

   パスの先頭はスラッシュ（/）ではなく疑問符（?）で、これは無効です。したがって、Apigee Edge は 500 Internal Server Error をエラーコード protocol.http.BadPath とともに返します。

   サンプル 2

   サンプル #2: JavaScript ポリシーがリクエスト ヘッダーの値に基づいて target.url 変数を更新する

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);
   

   上記のサンプルでは、変数 url に含まれる値 https://mocktarget.apigee.net と、 request.header.Path. から取得される別の変数 path の値を連結することで、フロー変数 target.url が更新されます。

   実際のリクエストまたはトレースにアクセスできる場合は、request.header.Path に渡される実際の値を確認できます。

   お客様によるリクエストの例

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   この例では、ヘッダーパスはリクエストの一部として送信されません。したがって、JavaScript ポリシーの変数 path の値は null です。

   それによって次のようになります。

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   target.url の値には次のコンポーネントが含まれます。

   • スキーム: https
   • authority: mocktarget.apigee.net
   • パス: ?user

   パスの先頭はスラッシュ（/）ではなく疑問符（?）で、これは無効です。したがって、Apigee Edge は 500 Internal Server Error をエラーコード protocol.http.BadPath とともに返します。

   サンプル 3

   サンプル #3: AssignMessage ポリシーで target.url 変数を更新する

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

   url の値には次のコンポーネントが含まれます。

   • スキーム: https
   • authority: mocktarget.apigee.net
   • パス: ?echo

   この例でも、パスの先頭はスラッシュ（/）ではなく疑問符（?）ですが、これは無効です。したがって、Apigee Edge は 500 Internal Server Error をエラーコード protocol.http.BadPath とともに返します。

解像度

URL 仕様 RFC 3986、セクション 3: 構文コンポーネントに従い、path コンポーネントは必須で、常に「"/"」で始まらなければなりません。したがって、次の手順に沿ってこの問題を解決します。

1. フロー変数 target.url で表されるバックエンド サーバーの URL には、常に有効なパスがあり、常にスラッシュ（/）で始まるようにします。
   1. 場合によっては、パスにリソース名が含まれない場合は、少なくともパスにスラッシュ（/）があることを確認してください。
   2. フロー変数 target.url の値を他の変数で決定する場合は、他の変数に無効なパスが含まれないようにします。
   3. フロー変数 target.url の値を決定するために文字列オペレーションを実行する場合は、文字列オペレーションの結果または結果に無効なパスが含まれないようにします。

2. 上記のサンプルでは、次のようにこの問題を解決できます。

   サンプル 1

   サンプル #1: JavaScript ポリシーで target.url 変数を更新する

   この問題を解決するには、次のように変数 url で疑問符（?）ではなくスラッシュ（/）を使用します。

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);
   

   サンプル 2

   サンプル #2: JavaScript ポリシーがリクエスト ヘッダーの値に基づいて target.url 変数を更新する

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);
   

   この問題を解決するには、次のように有効なパス（例: /user）をリクエスト ヘッダー Path の一部として渡してください。

   リクエストの例:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   サンプル 3

   サンプル #3: AssignMessage ポリシーで target.url 変数を更新する

   AssignMessage ポリシーの <Value> 要素に有効なパスを追加します。この問題を解決するには、以下に示すように、<Value> 要素内の疑問符（?） を スラッシュ（/） に置き換えて、https://mocktarget.apigee.net/echo に設定してください。

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>
   

   仕様

   次の仕様に従い、バックエンド サーバー URL の path コンポーネントは常に スラッシュ（/） で始まらなければなりません。

   仕様
   RFC 3986 のセクション 3: 構文コンポーネント
   RFC 3986 のセクション 3.3: パス

   Apigee サポートのサポートが必要な場合は、診断情報の収集が必要な場合をご覧ください。

   診断情報の収集が必要な場合

   上記の手順でも問題が解決しない場合は、次の診断情報を収集して Apigee Edge サポートに連絡してください。

   Public Cloud ユーザーの場合は、次の情報を入力します。

   • 組織の名前
   • 環境名
   • API プロキシの名前
   • エラーコード protocol.http.BadPath の 500 Internal Server Error を再現するために使用する curl コマンドを完了します。
   • API リクエストのトレース ファイル

   Private Cloud ユーザーの場合は、次の情報を入力します。

   • 失敗したリクエストについて確認された完全なエラー メッセージ
   • 環境名
   • API プロキシ バンドル
   • API リクエストのトレース ファイル

   • NGINX アクセスログ:

     /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

     ここで、ORG、ENV、PORT# は実際の値に置き換えられます。

   • Message Processor のシステムログ /opt/apigee/var/log/edge-message- processor/logs/system.log

   参照

   フロー変数 - ターゲット