502 Bad Gateway - Response 405 without Allow Header (502 Ошибка шлюза – ответ 405 без заголовка Allow)

Мониторинг API

Чтобы диагностировать ошибку с помощью мониторинга API:

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

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

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

5. Постройте график Код ошибки по оси Y и Время по оси X.

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. Убедитесь, что включен параметр Показывать все FlowInfo:

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

5. Обычно ошибка возникает в потоке после этапа Запрос отправлен на целевой сервер, как показано ниже.

   

6. Запишите значение ошибки из трассировки.

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

7. Перейдите к фазе AX (запись данных аналитики) в трассировке и нажмите на нее.

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 policy или RaiseFault policy, и задайте код статуса 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.

   Пример конфигурации TargetEndpoint с 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. Настройте свойство в Message Processor, чтобы Apigee Edge не возвращал ошибку 502

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