<ph type="x-smartling-placeholder"></ph>
現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。 詳細
症状
クライアント アプリケーションは、次の HTTP ステータス コード 500 Internal Server Error を取得します。
API 呼び出しのレスポンスとしてエラーコード protocol.http.BadPath。
エラー メッセージ
クライアント アプリケーションが次のレスポンス コードを受け取ります。
HTTP/1.1 500 Internal Server Error
また、次のエラー メッセージが表示される場合があります。
{
"fault":{
"faultstring":"Invalid request path",
"detail":{
"errorcode":"protocol.http.BadPath"
}
}
}考えられる原因
このエラーは、フロー変数で表されるバックエンド サーバーのリクエスト URL が
target.url,
代わりに疑問符(?)で始まる path が含まれている
スラッシュ(/)は無効です。
仕様に基づく <ph type="x-smartling-placeholder"></ph> RFC 3986 のセクション 3: Syntax Components と <ph type="x-smartling-placeholder"></ph> RFC 3986、セクション 3.3: Path:
URI の構文 には次のコンポーネントがあります。
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragmentpathコンポーネントは必須で、先頭と末尾で指定する必要があります。 必ずスラッシュ(/)を付けます。
したがって、バックエンド サーバーのリクエスト URL に path コンポーネントが含まれている場合、
スラッシュ(/)ではなく疑問符(?)を使用した場合、Apigee
Edge が 500 Internal Server Error とエラーコードを返す
protocol.http.BadPath。
たとえば、target.url の値が
https://www.mocktarget.apigee.net?json の場合、このエラーは
path は疑問符で始まるため、無効である
(?)をスラッシュ(/)の代わりに使用しないでください。
| 原因 | 説明 | トラブルシューティングの実施対象 |
|---|---|---|
| バックエンド サーバーの URL(target.url)のパスが無効です | フロー変数で表されるバックエンド サーバー URL のパス コンポーネント
target.url の先頭が先頭ではなく疑問符(?)になっている
スラッシュ(/)を使用します。 |
Edge Public Cloud ユーザーと Edge Private Cloud ユーザー |
共通の診断手順
このエラーを診断するには、次のいずれかのツールまたは手法を使用します。
API Monitoring
手順 #1: API Monitoring を使用する
<ph type="x-smartling-placeholder">API Monitoring を使用してエラーを診断するには:
- <ph type="x-smartling-placeholder"></ph> Apigee Edge UI にログインするユーザーとして、 付与します。
問題を調査する組織に切り替えます。
- [Analyze] >API モニタリング >Investigate ページをご覧ください。
- エラーが発生した期間を選択します。
障害コードを Time に対してプロットします。
<ph type="x-smartling-placeholder">次に示すように、障害コード
protocol.http.BadPathを持つセルを選択します。 下にあります。
障害コード
protocol.http.BadPathに関する情報が次のように表示されます。 下に示します。
[ログを表示 ] をクリックし、失敗したリクエストの行を開きます。
- [ログ] ウィンドウで、次の詳細をメモします。
<ph type="x-smartling-placeholder">
- </ph>
- ステータス コード:
500 - 障害の発生元:
target - 障害コード:
protocol.http.BadPath
- ステータス コード:
- [Fault Source] が
targetで [Fault Code] がprotocol.http.BadPathの場合は、バックエンド サーバーの URL に 無効なパスです。
トレース
手順 2: Trace ツールを使用する
<ph type="x-smartling-placeholder">Trace ツールを使用してエラーを診断するには:
- トレース セッションを有効にし、以下のいずれかを行います。
<ph type="x-smartling-placeholder">
- </ph>
500 Internal Server Errorエラーが発生するのを待つ。または- 問題を再現できる場合は、API 呼び出しを行って問題を再現してください。
500 Internal Server Error
[Show all FlowInfos] が有効になっていることを確認します。

- 失敗したリクエストのいずれかを選択し、トレースを調べます。
- トレースのさまざまなフェーズを移動して、エラーが発生した場所を特定します。
このエラーは通常、Target Request Flow Started の後のフローで発生します 示されます。

トレースのエラーの値をメモします。
error: Invalid request path(エラー: リクエストパスが無効です)
このエラーは、Target Request Flow Started の後に Apigee Edge によって発生したため バックエンド サーバーの URL に無効なパスが含まれていることを示しています。この場合、 URL を表すフロー変数
target.urlが (バックエンド サーバー用)が無効なパスで更新された可能性があります。 いずれか 1 つのポリシーが適用されます。- それぞれのフローで [Variables Read and Assigned] セクションを確認します。 エラーフローからターゲット リクエスト フローの開始フェーズに移行します。
- フロー変数
target.urlがあったポリシーを特定する 最終更新:JavaScript ポリシーがフロー変数を更新したことを示すサンプル トレース
target.url:
上記のサンプル トレースで、フロー変数の値をメモします。
target.urlは、JS- SetTargetURLという名前の JavaScript ポリシーで次のように更新されます。target.url : https://mocktarget.apigee.net?json target.urlの値には次のコンポーネントが含まれます。 <ph type="x-smartling-placeholder">- </ph>
- スキーム:
https - 認証機関:
mocktarget.apigee.net - パス:
?json
- スキーム:
- path コンポーネントは疑問符(
?)で始まるため スラッシュ(/)ではなくInvalid request path。 - トレースの [AX(Analytics Data Recorded)] フェーズに移動してクリックします。
[Phase Details] - [Error Headers] セクションまで下にスクロールし、 次のように、X-Apigee-fault-code と X-Apigee-fault-source の値を設定します。

X-Apigee-fault-code と X-Apigee-fault-source の値が表示されます。 を
protocol.http.BadPath、targetとしています。 バックエンド サーバーの URL に無効なパスがあるためにこのエラーが起きたことを示します。レスポンス ヘッダー 値 X-Apigee-fault-code protocol.http.BadPathX-Apigee-fault-source target
NGINX
手順 #3: NGINX アクセスログを使用する
<ph type="x-smartling-placeholder">NGINX アクセスログを使用してエラーを診断するには:
- Private Cloud ユーザーの場合は、NGINX アクセスログを使用して、
HTTP
500 Internal Server Errorに関する重要な情報。 NGINX アクセスログを確認します。
<ph type="x-smartling-placeholder">/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log- エラーコードを含む
500エラーがないか検索します 特定の期間にprotocol.http.BadPath( または、まだ500で失敗しているリクエストがあるかどうか。 X-Apigee-fault-code が一致する
500エラーがある場合protocol.http.BadPathの値を取得してから、X- Apigee-fault-source。NGINX アクセスログの 500 エラーの例:
NGINX アクセスログの上記のサンプル エントリには、X-Apigee- fault-code と X-Apigee-fault-source:
ヘッダー 値 X-Apigee-fault-code protocol.http.BadPathX-Apigee-fault-source targetX-Apigee-fault-codeX-Apigee-fault-code と X-Apigee-fault-sourceX-Apigee-fault-code の値がそれぞれ それぞれ
protocol.http.BadPathとtargetであり、 バックエンド サーバーの URL に無効なパスが含まれていることが原因です。
原因: バックエンド サーバーの URL(target.url)のパスが無効です
診断
- API Monitoring、Trace ツール、または NGINX アクセスログを使用して、
500 Internal Server Errorの障害コードと障害ソースを特定します。詳しくは、 一般的な診断手順。 - 障害コードが
protocol.http.BadPathで、障害ソースが 値targetの場合は、バックエンド サーバーの URL に無効な URL が あります。 バックエンド サーバーの URL は、Apigee のフロー変数
<ph type="x-smartling-placeholder">target.urlで表されます。 。このエラーは通常、バックエンド サーバーの URL を更新しようとした場合に発生します。 (target.url)動的に( プロキシや共有フローなど)をターゲット リクエスト フローで処理し、無効なパスを持つようにします。フロー変数
target.urlに無効な値が含まれているかどうかを判定します。 path とその値のソースを、次のいずれかの方法で指定します。トレース
Trace ツールの使用
このエラーのトレースをキャプチャした場合は、 Trace ツールの使用 と
target.urlに無効なパスがあるかどうか、つまり、パスが始まっているかどうかを確認する スラッシュ(/)の代わりに疑問符(?)を使用する。「はい」の場合、
target.urlに無効なパスを含めます。JavaScript ポリシーがフロー変数を更新したことを示すサンプル トレース
target.url
- 上記のサンプル トレースでは、JavaScript ポリシーによって、無効なパスを含むように
target.urlの値が変更または更新されています。 target.urlには次のコンポーネントがあります。 <ph type="x-smartling-placeholder">- </ph>
- スキーム:
https - 認証機関:
mocktarget.apigee.net - パス:
?json
パスは前方ではなく疑問符(
?)で始まっている スラッシュ(/) があるため、無効です。- スキーム:
ログ
ログサーバーでのログの使用
- このエラーのトレースがない場合(断続的に発生する問題)は、
フロー変数の値に関する情報がログに記録され、
target.url(次のようなポリシーを使用) <ph type="x-smartling-placeholder"></ph> MessageLogging または <ph type="x-smartling-placeholder"></ph> ServiceCallout ポリシーをログサーバーに追加します。 - ログがある場合は、それらを確認して
<ph type="x-smartling-placeholder">
- </ph>
target.urlに無効なパスがあるかどうか確認します。また、- 変更されたポリシーに関する情報を特定できるかどうかを確認する
target.url: 無効なパスを含めます
API プロキシ
失敗した API プロキシの確認
このエラーのトレースやログがない場合は、失敗した API を確認してください。 プロキシを使用して、フロー変数
target.urlを変更または更新された内容を特定 無効なパスが含まれている可能性があります。次の点を確認してください。- API プロキシ内のポリシー
- プロキシから呼び出される共有フロー
変更または変更を行う特定のポリシー(AssignMessage や JavaScript など)を慎重に調査します。 フロー変数
target.urlを更新し、target.urlを更新して無効なパスを指定する。フロー変数
target.urlを更新するポリシーの例を次に示します。 誤って無効なパスが含まれていると、このエラーが発生します。サンプル 1
サンプル 1:
target.url変数を更新する JavaScript ポリシーvar url = "https://mocktarget.apigee.net?json" context.setVariable("target.url", url);
上記のサンプルでは、フロー変数
target.urlが更新されています。 値https://mocktarget.apigee.net?jsonが別の 変数url.urlの値には次のコンポーネントが含まれます。- スキーム:
https - 認証機関:
mocktarget.apigee.net - パス:
?json
パスはスラッシュではなく疑問符(
?)で始まっている (/)は無効です。したがって、Apigee Edge は500 Internal Server Error(エラーコード:protocol.http.BadPath)。サンプル 2
サンプル 2:
target.url変数を更新する JavaScript ポリシー リクエスト ヘッダーの値に基づいてvar path = context.getVariable("request.header.Path"); var url = "https://mocktarget.apigee.net" + path context.setVariable("target.url", url);
上記のサンプルでは、フロー変数
target.urlが更新されています。 配列に含まれる値https://mocktarget.apigee.netを連結して、 変数url、 別の変数pathの値、 値がrequest.header.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 + pathurl = https://mocktarget.apigee.net + "?user"target.url = https://mocktarget.apigee.net?user
target.urlの値には次のコンポーネントが含まれます。- スキーム:
https - 認証機関:
mocktarget.apigee.net - パス:
?user
パスはスラッシュではなく疑問符(
?)で始まっている (/)は無効です。したがって、Apigee Edge はエラーコードprotocol.http.BadPathとともに500 Internal Server Errorを返します。サンプル 3
サンプル 3:
target.url変数を更新する AssignMessage ポリシー<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 - 認証機関:
mocktarget.apigee.net - パス:
?echo
この例でも、パスは疑問符(
?)で始まります。 スラッシュ(/)の代わりに使用してください。これは無効です。したがって、 Apigee Edge がエラーコードとともに500 Internal Server Errorを返すprotocol.http.BadPath。- スキーム:
解決策
URL 仕様に従う
<ph type="x-smartling-placeholder"></ph>
RFC 3986、セクション 3: Syntax Components では、path コンポーネントが必須です。
また、先頭は常に「"/」で始める必要があります。次の手順に沿って問題を解決してください。
- フロー変数で表されるバックエンド サーバーの URL を確認する
target.urlには常に有効なパスがあり、常に スラッシュ(/)。 <ph type="x-smartling-placeholder">- </ph>
- パスにリソース名が存在しない場合は、
少なくともスラッシュ(
/)がある。 - 他の変数を使用してフロー変数の値を決定する場合
target.url。次に、他の変数に 無効なパスです。 - フロー変数の値を決定する文字列オペレーションを実行する場合
target.urlの場合は、文字列の結果または結果が 無効なパスがないことを確認します。
- パスにリソース名が存在しない場合は、
少なくともスラッシュ(
上記のサンプルでは、この問題を解決できます。手順は次のとおりです。
サンプル 1
サンプル 1:
target.url変数を更新する JavaScript ポリシー疑問符(
?)の代わりにスラッシュ(/)を 次のように変数urlを使用して、この問題を修正します。var url = "https://mocktarget.apigee.net/json" context.setVariable("target.url", url);
サンプル 2
サンプル 2:
target.url変数を更新する JavaScript ポリシー リクエスト ヘッダーの値に基づいて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:
target.url変数を更新する AssignMessage ポリシー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コンポーネント が 次に示すように、必ず スラッシュ(/) で始めなければなりません。 仕様:仕様 <ph type="x-smartling-placeholder"></ph> RFC 3986、セクション 3: Syntax Components <ph type="x-smartling-placeholder"></ph> 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
参照