500 サーバーエラー - BadPath

ここに表示されているのは Apigee Edge のドキュメントです。
Go to the Apigee X のドキュメントに移動します。 info

症状

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

エラー メッセージ

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

HTTP/1.1 500 Internal Server Error

さらに、次のエラー メッセージも確認できます。

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

考えられる原因

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

仕様 RFC 3986、セクション 3: Syntax Components と RFC 3986、セクション 3.3: Pathに準拠しています。

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 がスラッシュ（/）ではなく疑問符（?）で始まるため、無効 となり、このエラーが発生します。

共通の診断手順

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

原因: バックエンド サーバーの 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 ツールを使用する で説明されている手順に沿って操作します。

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

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

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

      
   3. 上記のトレース例では、JavaScript ポリシーが target.url の値を変更または更新して、無効なパスを含めていることがわかります。
   4. target.url には次のコンポーネントが含まれています。
      • scheme: https
      • authority: mocktarget.apigee.net
      • path: ?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 の値には次のコンポーネントが含まれています。

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?json

   パスはスラッシュ（/）ではなく疑問符（?）で始まっているため、, 無効です。そのため、Apigee Edge はエラーコード protocol.http.BadPath で 500 Internal Server Error を返します。

   サンプル 2

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

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

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

   実際のリクエストまたはトレースにアクセスできる場合は、渡された実際の値 を 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 の値には次のコンポーネントが含まれています。

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?user

   パスはスラッシュ （/）ではなく疑問符（?）で始まっているため、無効です。そのため、Apigee Edge はエラーコード protocol.http.BadPath で 500 Internal Server Error を返します。

   サンプル 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 の値には次のコンポーネントが含まれています。

   • scheme: https
   • authority: mocktarget.apigee.net
   • path: ?echo

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

解決策

URL 仕様 RFC 3986、セクション 3: Syntax Components に準拠して、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);

   次の例に示すように、リクエスト ヘッダー Path の一部として有効なパス（/user など）を渡して、この問題を解決します。

   リクエスト例:

   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>

   仕様

   Apigee Edge では、次の仕様に準拠して、バックエンド サーバーの URL の path コンポーネント は必ずスラッシュ（/） で始まる必要があります。

   仕様
   RFC 3986、セクション 3: Syntax Components
   RFC 3986、セクション 3.3: Path

   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

   参照

   フロー変数 - target