502 Bad Gateway — ответ 405 без заголовка Allow

Мониторинг API

Для диагностики ошибки с помощью мониторинга API:

1. Войдите в пользовательский интерфейс Edge под учетной записью пользователя с соответствующей ролью .

2. Переключитесь на организацию, в которой вы хотите расследовать проблему.

   
3. Перейдите на страницу Анализ > Мониторинг API > Исследование .
4. Выберите конкретный временной промежуток, в течение которого вы наблюдали ошибки.

5. Постройте график зависимости кода ошибки от времени .

6. Выберите ячейку, содержащую код ошибки protocol.http.Response405WithoutAllowHeader , как показано ниже:

   

7. Информация о коде ошибки protocol.http.Response405WithoutAllowHeader отображается следующим образом:

   

8. Нажмите «Просмотреть журналы» и разверните один из неудачных запросов, чтобы просмотреть дополнительную информацию.

   
9. В окне «Журналы» обратите внимание на следующие сведения:
   • Код состояния: 502
   • Источник неисправности: target
   • Код ошибки: protocol.http.Response405WithoutAllowHeader .
10. Если источником ошибки является target , а код ошибки равен protocol.http.Response405WithoutAllowHeader , это означает, что серверная часть ответила кодом состояния 405 Method Not Allowed без заголовка Allow .

инструмент трассировки

Для диагностики ошибки с помощью инструмента трассировки:

1. Включите сеанс трассировки и либо
   • Дождитесь появления ошибки 502 Bad Gateway , или
   • Если вы можете воспроизвести проблему, выполните вызов API для воспроизведения ошибки - 502 Bad Gateway

2. Убедитесь, что параметр «Показывать все FlowInfos» включен:

   
3. Выберите один из запросов, завершившихся неудачей, и изучите трассировку.
4. Проследите за различными этапами трассировки и определите место возникновения сбоя.

5. Как правило, ошибка возникает после этапа отправки запроса на целевой сервер , как показано ниже:

   

6. Обратите внимание на значение ошибки, полученное из трассировки.

   Приведенный выше пример трассировки показывает ошибку « Received 405 Response without Allow Header . Поскольку ошибка возникает в Apigee после отправки запроса на бэкэнд-сервер, это указывает на то, что бэкэнд-сервер отправил код состояния 405 без заголовка Allow .

7. Перейдите к этапу AX (Analytics Data Recorded) в трассировке и щелкните по нему.

8. В панели «Подробности этапа» прокрутите вниз до раздела «Заголовки ошибок/ответов» и определите значения X-Apigee-fault-code и X-Apigee-fault-source, как показано ниже:

   
9. Вы увидите значения X-Apigee-fault-code и X-Apigee-fault-source как protocol.http.Response405WithoutAllowHeader и target соответственно, что указывает на то, что эта ошибка вызвана тем, что бэкэнд отправил код состояния ответа 405 без заголовка Allow .

   Заголовки ответа	Ценить
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

NGINX

Для диагностики ошибки с помощью журналов доступа NGINX:

1. Если вы используете частное облако , то можете использовать журналы доступа NGINX для получения ключевой информации об ошибках HTTP 502 .

2. Проверьте журналы доступа NGINX:

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

   Где: ORG , ORG и PORT# заменяются фактическими значениями.

3. Выполните поиск, чтобы проверить наличие ошибок 502 с кодом ошибки protocol.http.Response405WithoutAllowHeader за определенный период времени (если проблема возникала ранее) или если какие-либо запросы по-прежнему завершаются с ошибкой 502 .

4. Если вы обнаружите ошибки 502 с кодом X-Apigee-fault-code, соответствующим значению protocol.http.Response405WithoutAllowHeader , определите значение X-Apigee-fault-source.

   Пример ошибки 502 из журнала доступа NGINX:

   

   Приведенная выше запись из журнала доступа NGINX содержит следующие значения для X-Apigee-fault-code и X-Apigee-fault-source:

   Заголовки ответа	Ценить
   X-Apigee-fault-code	protocol.http.Response405WithoutAllowHeader
   X-Apigee-fault-source	target

бэкенд-сервер

Вариант №1: Настройте серверную часть так, чтобы она отправляла код состояния 405 с заголовком Allow:

1. Убедитесь, что серверная часть всегда соответствует спецификации RFC 7231, раздел 6.5.5: 405 Method Not Allowed , и отправляет сообщение с кодом состояния 405 , включив список разрешенных методов в заголовок Allow как показано ниже:

   Allow: HTTP_METHODS

2. Например, если ваш бэкэнд-сервер разрешает методы GET , POST и HEAD , то вам необходимо убедиться, что заголовок Allow содержит их следующим образом:

   Allow: GET, POST, HEAD

Обработка ошибок

Вариант №2: Используйте обработку ошибок для отправки кода состояния 405 с заголовком Allow из вашего API-прокси:

Если серверная часть возвращает код состояния 405 без заголовка Allow , вы можете использовать обработку ошибок, чтобы отправить ответ с кодом состояния 405 и заголовком Allow от вашего API-прокси следующим образом:

1. Создайте политику, например, политику AssignMessage или политику RaiseFault , и установите код состояния 405 с заголовком Allow и пользовательским сообщением.

   Пример политики AssignMessage для отправки ошибки 405 с заголовком Allow:

   <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>

2. Создайте FaultRule в TargetEndpoint , которое будет вызывать политику при получении ошибки 502 с кодом ошибки protocol.http.Response405WithoutAllowHeader .

   Пример конфигурации TargetEnpoint, демонстрирующий правило обработки ошибок (FaultRule):

   <TargetEndpoint name="default">
   ...
       <FaultRules>
          <FaultRule name="405WithoutAllowHeader">
               <Step>
                   <Name>AM-405WithAllowHeader</Name>
               </Step>
               <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition>
           </FaultRule>
       </FaultRules>

3. Сохраните эти изменения в новой версии вашего API-прокси и разверните эту версию.
4. Выполните вызовы API и убедитесь, что получаете код состояния 405 с заголовком Allow .

Настройка свойства

Вариант №3: Настройте свойство в обработчике сообщений, чтобы предотвратить возврат ошибки 502 со стороны Apigee Edge.

1. Если вы используете частное облако , вы можете изменить свойство HTTP.ignore.allow_header.for.405 на true , чтобы предотвратить выдачу ошибки 502 сервером Apigee Edge, даже если серверная часть отвечает кодом состояния 405 без заголовка Allow , используя руководство: Настройка игнорирования заголовка allow для 405 в обработчиках сообщений .
2. Если вы используете публичное облако, пожалуйста, обратитесь в службу поддержки Apigee Edge.