<ph type="x-smartling-placeholder"></ph>
現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。 詳細
症状
クライアント アプリケーションが HTTP ステータス コード 502 Bad Gateway とエラーを取得する
API 呼び出しのレスポンスとしてコード protocol.http.Response405WithoutAllowHeader を渡します。
エラー メッセージ
クライアント アプリケーションが次のレスポンス コードを受け取ります。
HTTP/1.1 502 Bad Gateway
また、次のエラー メッセージが表示される場合があります。
{
"fault":{
"faultstring":"Received 405 Response without Allow Header",
"detail":{
"errorcode":"protocol.http.Response405WithoutAllowHeader"
}
}
}考えられる原因
このエラーは、バックエンド サーバーが 405 Method Not Allowed ステータスで応答した場合に発生します。
Allow ヘッダーのないコードを追加します。
仕様に従う
<ph type="x-smartling-placeholder"></ph>
RFC 7231、セクション 6.5.5: 405 Method Not Allowed に該当する場合、配信元サーバーが
405 レスポンスで、次を含む Allow ヘッダー フィールドを生成して送信しなければなりません。
ターゲット リソースで現在サポートされているメソッドのリスト。そうでない場合、Apigee から
502 Bad Gateway、エラーコード protocol.http.Response405WithoutAllowHeader。
| 原因 | 説明 | トラブルシューティングの実施対象 |
|---|---|---|
| バックエンド サーバーからの Allow ヘッダーのない 405 レスポンス | API リクエストを処理しているバックエンド サーバーが、Allow ヘッダーなしで 405 ステータス コードを返します。 |
Edge Public Cloud ユーザーと Edge Private Cloud ユーザー |
共通の診断手順
このエラーを診断するには、次のいずれかのツールまたは手法を使用します。
API Monitoring
<ph type="x-smartling-placeholder">API Monitoring を使用してエラーを診断するには:
- Edge UI に、 付与します。
問題を調査する組織に切り替えます。
- [Analyze] >API モニタリング >Investigate ページをご覧ください。
- エラーが発生した期間を選択します。
障害コードを Time に対してプロットします。
<ph type="x-smartling-placeholder">障害コードが含まれているセルを選択してください 次のように
protocol.http.Response405WithoutAllowHeaderします。
障害コード
protocol.http.Response405WithoutAllowHeaderに関する情報 次のように表示されます。
[ログを表示 ] をクリックし、失敗したリクエストの 1 つを開いて詳細情報を表示します。
- [ログ] ウィンドウで、次の詳細をメモします。
<ph type="x-smartling-placeholder">
- </ph>
- ステータス コード:
502 - 障害の発生元:
target - 障害コード:
protocol.http.Response405WithoutAllowHeader
- ステータス コード:
- [Fault Source] が
targetで [Fault Code] がprotocol.http.Response405WithoutAllowHeaderの場合、これはバックエンドが サーバーが405 Method Not Allowedステータス コードを返し、応答がありませんでした。Allowヘッダー。
Trace ツール
<ph type="x-smartling-placeholder">Trace ツールを使用してエラーを診断するには:
- を有効にする
トレース セッションと、
<ph type="x-smartling-placeholder">
- </ph>
502 Bad Gatewayエラーが発生するのを待つ。または- 問題を再現できる場合は、API 呼び出しを行って問題を再現してください。
502 Bad Gateway件のエラー
[Show all FlowInfos] が有効になっていることを確認します。
- 失敗したリクエストのいずれかを選択し、トレースを調べます。
- トレースのさまざまなフェーズを移動して、エラーが発生した場所を特定します。
このエラーは通常、Request sent to target server の後のフローで発生します。 示されます。
トレースのエラーの値をメモします。
上記のサンプル トレースでは、エラーが
Received 405 Response without Allow Headerと表示されます。リクエストがバックエンドに送信された後に Apigee によってエラーが生成されるため バックエンド サーバーが405レスポンス ステータス コードを送信したことを示します。 をAllowヘッダーなしで取得します。- トレースの [AX(Analytics Data Recorded)] フェーズに移動してクリックします。
[Phase Details] の [Error / Response Headers] セクションまで下にスクロールします。 パネルで 次のように、X-Apigee-fault-code と X-Apigee-fault-source の値を設定します。
- X-Apigee-fault-codeX-Apigee-fault-code と X-Apigee-fault-sourceX-Apigee-fault-code の値が次のように表示されます。
それぞれ
protocol.http.Response405WithoutAllowHeaderとtargetです。 これは、このエラーの原因は、バックエンドがAllowヘッダーのない405レスポンス ステータス コード。レスポンス ヘッダー 値 X-Apigee-fault-code protocol.http.Response405WithoutAllowHeaderX-Apigee-fault-source target
NGINX
<ph type="x-smartling-placeholder">NGINX アクセスログを使用してエラーを診断するには:
- プライベート クラウド ユーザーは、NGINX アクセスログを使用して、
HTTP
502エラーに関する主要な情報。 NGINX アクセスログを確認します。
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
ここで、 ORG、ORG、PORT# は実際の値に置き換えます。
- エラーコードを含む
502エラーがないか検索します 特定の期間にprotocol.http.Response405WithoutAllowHeader(ユーザーが 過去に発生した問題)またはイベントで引き続き失敗するリクエストが502。 X-Apigee-fault-code が
502値protocol.http.Response405WithoutAllowHeaderの値を求め、 X-Apigee-fault-source. の値。NGINX アクセスログの 502 エラーの例:
NGINX アクセスログの上記のサンプル エントリには、X-Apigee- fault-code と X-Apigee-fault-source:
レスポンス ヘッダー 値 X-Apigee-fault-code protocol.http.Response405WithoutAllowHeaderX-Apigee-fault-source target
原因: バックエンド サーバーからの Allow ヘッダーのない 405 レスポンス
診断
502 Bad Gatewayの障害コードと障害の発生元を特定します。 API Monitoring、Trace Tool、または NGINX アクセスログを使用する 一般的な診断手順。- 障害コードが
protocol.http.Response405WithoutAllowHeaderで、 Fault Source の値がtargetの場合、これはバックエンド サーバーで が、Allowヘッダーなしで405ステータス コードを返しました。したがって、 Apigee がエラーコードで502 Bad Gatewayを返します。protocol.http.Response405WithoutAllowHeader。
解決策
問題を解決するには、次のいずれかの方法を使用します。
バックエンド サーバー
オプション 1: Allow ヘッダーで 405 ステータス コードを送信するようにバックエンド サーバーを修正します。
<ph type="x-smartling-placeholder">バックエンド サーバーが常に仕様を遵守していることを確認する <ph type="x-smartling-placeholder"></ph> RFC 7231、セクション 6.5.5: 405 Method Not Allowed を使用し、
405ステータスで送信します。 許可するメソッドのリストをAllowヘッダーの一部として含めることで、コードにコードを書き込める 次のように指定します。Allow: HTTP_METHODS
- たとえば、バックエンド サーバーが
GET、POST、およびHEADメソッドを使う場合、Allowヘッダーに 次のように指定します。Allow: GET, POST, HEAD
障害処理
オプション 2: 障害処理を使用して、API から Allow ヘッダーと 405 ステータス コードを送信する proxy:
<ph type="x-smartling-placeholder">
バックエンド サーバーが Allow なしで 405 ステータス コードを返す場合
ヘッダーに対して、障害処理を使用して 405 ステータス コードと
次のように、API プロキシから Allow ヘッダーを取得する必要があります。
たとえば、 AssignMessage ポリシー または RaiseFault ポリシー ステータス コードを
405(Allowヘッダーとカスタム)に設定します。 表示されます。Allow ヘッダーを使用して 405 を送信する AssignMessage ポリシーの例:
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader"> <DisplayName>AM-405WithAllowHeader</DisplayName> <Set> <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload> <StatusCode>405</StatusCode> <ReasonPhrase>Method Not Allowed</ReasonPhrase> </Set> <Add> <Headers> <Header name="Allow">GET, POST, HEAD</Header> </Headers> </Add> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
ポリシーを呼び出す
FaultRuleをTargetEndpointに作成する エラーコードとともに502エラーが表示された場合protocol.http.Response405WithoutAllowHeader。FaultRule を示す TargetEndpoint 構成の例:
<TargetEndpoint name="default"> ... <FaultRules> <FaultRule name="405WithoutAllowHeader"> <Step> <Name>AM-405WithAllowHeader</Name> </Step> <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition> </FaultRule> </FaultRules>- これらの変更を API プロキシの新しいリビジョンに保存し、そのリビジョンをデプロイします。
- API 呼び出しを実行し、次のコマンドを実行すると
405ステータス コードが返されることを確認します。Allowヘッダー。
プロパティの構成
オプション 3: Message Processor でプロパティを構成して Apigee Edge で 502 エラーが返される
- Private Cloud ユーザーは、プロパティを更新できます
HTTP.ignore.allow_header.for.405をtrueに変更し、Apigee Edge が バックエンド サーバーが405と応答しても502エラーが発生する ステータス コード(Allowヘッダーなし)(入門ガイドを使用): Message Processor で 405 プロパティの ignore allow ヘッダーを構成する。 - Public Cloud ユーザー の場合は、Apigee Edge サポートにお問い合わせください。
仕様
Apigee は、バックエンド サーバーからの 405 Method Not Allowed レスポンスを想定します。
次の仕様に従って Allow ヘッダーに置き換えます。
| 仕様 | |
|---|---|
| <ph type="x-smartling-placeholder"></ph> RFC 7231、セクション 6.5.5: 405 Method Not Allowed | |
| <ph type="x-smartling-placeholder"></ph> RFC 7231、セクション 7.4.1: Allow |
主な注意点
推奨される解決策は、405 ステータス コードを送信するようにバックエンド サーバーを修正することです。
Allow ヘッダーを使用し、仕様に従う
<ph type="x-smartling-placeholder"></ph>
RFC 7231、セクション 6.5.5: 405 Method Not Allowed をご覧ください。
Apigee サポートのサポートが必要な場合は、にアクセスしてください。 診断情報の収集が必要な場合。
診断情報の収集が必要な場合
上記の手順でも問題が解決しない場合は、以下の情報を収集します。 Apigee Edge サポートにお問い合わせください。
Public Cloud ユーザーの場合は、次の情報を提供します。
- 組織名
- 環境名
- API プロキシ名
- 次のコマンドで
502 Bad Gatewayを再現するためのcurlコマンドを完成させました。 エラーコードprotocol.http.Response405WithoutAllowHeader - API リクエストのトレース ファイル
Private Cloud ユーザーの場合は、次の情報を提供します。
- 失敗したリクエストについて観測された完全なエラー メッセージ
- 環境名
- API プロキシ バンドル
- API リクエストのトレース ファイル
NGINX アクセスログ
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
ここで、 ORG、ORG、PORT# は実際の値に置き換えます。
- Message Processor システムログ
/opt/apigee/var/log/edge-message-processor/logs/system.log