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

API-мониторинг

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

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

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

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

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

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

   

7. Информация о коде неисправности protocol.http.Response405WithoutAllowHeader 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 (записанные аналитические данные) в трассировке и щелкните его.

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-код неисправности	protocol.http.Response405WithoutAllowHeader
   X-Apigee-источник-ошибки	target

НГИНКС

Чтобы диагностировать ошибку с помощью журналов доступа 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-код неисправности	protocol.http.Response405WithoutAllowHeader
   X-Apigee-источник-ошибки	target

Внутренний сервер

Вариант № 1. Исправьте внутренний сервер, чтобы он отправлял код состояния 405 с заголовком «Разрешить»:

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

   Allow: HTTP_METHODS

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

   Allow: GET, POST, HEAD

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

Вариант № 2. Используйте обработку ошибок, чтобы отправить код состояния 405 с заголовком «Разрешить» из вашего прокси-сервера 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 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. Настройте свойство в процессоре сообщений, чтобы Apigee Edge не возвращал ошибку 502.

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