500 Внутренняя ошибка сервера — BadPath

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X.
информация

Симптом

Клиентское приложение получает код состояния HTTP 500 Internal Server Error с кодом ошибки protocol.http.BadPath в качестве ответа на вызовы API.

Сообщение об ошибке

Клиентское приложение получает следующий код ответа:

HTTP/1.1 500 Internal Server Error

Кроме того, вы можете увидеть следующее сообщение об ошибке:

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

Возможные причины

Эта ошибка возникает, если URL-адрес запроса внутреннего сервера, представленный переменной потока target.url , содержит path который начинается с вопросительного знака ( ? ) вместо косой черты ( / ), что является недопустимым .

В соответствии со спецификациями RFC 3986, раздел 3: Синтаксические компоненты и RFC 3986, раздел 3.3: Путь :

  1. Синтаксис URI состоит из следующих компонентов:

            foo://example.com:8042/over/there?name=ferret#nose
            \_/   \______________/\_________/ \_________/ \__/
             |            |            |            |       |
          scheme      authority       path        query   fragment
    
  2. Компонент path является обязательным , и он ДОЛЖЕН начинаться с косой черты ( / ) и всегда иметь ее.

Таким образом, если 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 и Private Cloud

Общие этапы диагностики

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

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

Процедура № 1: Использование мониторинга API

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

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

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

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

  7. Информация о коде неисправности protocol.http.BadPath отображается, как показано ниже:

  8. Нажмите «Просмотреть журналы» и разверните строку с невыполненным запросом.

  9. В окне «Журналы» обратите внимание на следующие детали:
    • Код состояния: 500
    • Источник неисправности: target
    • Код ошибки: protocol.http.BadPath
  10. Если источником сбоя является target , а кодом сбояprotocol.http.BadPath , это означает, что URL-адрес внутреннего сервера имеет недопустимый путь.

След

Процедура № 2: Использование инструмента «Трассировка»

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

  1. Включите сеанс трассировки и либо
    • Дождитесь появления 500 Internal Server Error или
    • Если вы можете воспроизвести проблему, выполните вызов API, чтобы воспроизвести проблему 500 Internal Server Error
  2. Убедитесь, что параметр «Показать все FlowInfos» включен:

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

  6. Обратите внимание на значение ошибки из трассировки:

    ошибка: неверный путь запроса

    Поскольку ошибка возникает Apigee Edge после фазы запуска целевого потока запросов , это указывает на то, что URL-адрес внутреннего сервера имеет неверный путь . Скорее всего, это произойдет, если переменная потока target.url (которая представляет URL-адрес внутреннего сервера) в Apigee Edge была обновлена ​​с использованием недопустимого пути через одну из политик в целевом потоке запросов.

  7. Изучите раздел «Переменные, прочитанные и назначенные» в каждом потоке в обратном направлении от потока ошибок к фазе запуска целевого потока запросов .
  8. Определите политику, в которой переменная потока target.url было обновлено:

    Пример трассировки, показывающий, что политика JavaScript обновила переменную потока target.url:

    Обратите внимание, что в приведенном выше примере трассировки значение переменной потока target.url обновляется в политике JavaScript с именем JS- SetTargetURL следующим образом: target.url : https://mocktarget.apigee.net?json

  9. Обратите внимание, что значение в target.url состоит из следующих компонентов:
    • схема: https
    • Авторитет: mocktarget.apigee.net
    • путь: ?json
  10. Поскольку компонент пути начинается с вопросительного знака ( ? ) вместо косой черты ( / ), вы получаете сообщение об ошибке Invalid request path .
  11. Перейдите к этапу AX (записанные аналитические данные) в трассировке и щелкните его.
  12. Прокрутите вниз до раздела « Сведения о фазезаголовки ошибок» и определите значения X-Apigee-fault-code и X-Apigee-fault-source, как показано ниже:

  13. Вы увидите значения X-Apigee-fault-code и X-Apigee-fault-source как protocol.http.BadPath и target соответственно, что указывает на то, что эта ошибка вызвана тем, что URL-адрес внутреннего сервера имеет недопустимый путь.

    Заголовки ответов Ценить
    X-Apigee-код неисправности protocol.http.BadPath
    X-Apigee-источник-ошибки target

НГИНКС

Процедура №3: ​​Использование журналов доступа NGINX

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

  1. Если вы являетесь пользователем частного облака , вы можете использовать журналы доступа NGINX для определения ключевой информации о 500 Internal Server Error .
  2. Проверьте журналы доступа NGINX:

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

  3. Выполните поиск, чтобы узнать, есть ли какие-либо ошибки 500 с кодом ошибки protocol.http.BadPath в течение определенного периода времени (если проблема возникла в прошлом) или есть ли какие-либо запросы, которые по-прежнему не выполняются с 500 .
  4. Если вы обнаружите какие-либо 500 ошибок с кодом X-Apigee-fault-code , соответствующим значению protocol.http.BadPath , определите значение X-Apigee-fault-source.

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

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

    Заголовки Ценить
    X-Apigee-код неисправности protocol.http.BadPath
    X-Apigee-источник-ошибки target

    Обратите внимание, что значения X-Apigee-fault-code и X-Apigee-fault-source — это protocol.http.BadPath и target соответственно, что указывает на то, что эта ошибка вызвана тем, что URL-адрес внутреннего сервера имеет неверный путь .

Причина: URL-адрес внутреннего сервера (target.url) имеет неверный путь.

Диагностика

  1. Определите код ошибки и источник ошибки для 500 Internal Server Error с помощью мониторинга API, инструмента трассировки или журналов доступа NGINX, как описано в разделе «Общие шаги диагностики» .
  2. Если код ошибкиprotocol.http.BadPath , а источник ошибки имеет значение target , это означает, что URL-адрес внутреннего сервера имеет неверный путь .
  3. URL-адрес внутреннего сервера представлен переменной потока target.url в Apigee Edge. Эта ошибка обычно возникает, если вы пытаетесь динамически обновить URL-адрес внутреннего сервера ( target.url ), используя любую политику (внутри прокси-сервера или общего потока) в целевом потоке запросов, так что у него недопустимый путь .

  4. Определите, действительно ли переменная потока target.url имеет недопустимый путь и источник ее значения, используя один из следующих методов:

    След

    Использование инструмента «Трассировка»

    Если вы зафиксировали трассировку этой ошибки, выполните действия, описанные в разделе «Использование инструмента трассировки» , и

    1. Убедитесь, что target.url имеет недопустимый путь, то есть начинается ли он с вопросительного знака ( ? ) вместо косой черты ( / ).
    2. Если да, то найдите политику, которая изменила или обновила значение target.url , чтобы оно содержало недопустимый путь.

      Пример трассировки, показывающий, что политика JavaScript обновила переменную потока target.url

    3. Обратите внимание, что в приведенном выше примере трассировки политика JavaScript изменила или обновила значение target.url , чтобы оно содержало недопустимый путь.
    4. Обратите внимание, что target.url имеет следующие компоненты:
      • схема: https
      • Авторитет: mocktarget.apigee.net
      • путь: ?json

      Путь начинается с вопросительного знака ( ? ) вместо косой черты ( / ) , поэтому он недействителен.

    Журналы

    Использование журналов на вашем сервере журналов

    1. Если у вас нет трассировки этой ошибки (периодическая проблема), проверьте, записали ли вы информацию о значении переменной потока target.url , используя такие политики, как MessageLogging или ServiceCallout , на свой сервер журналов.
    2. Если у вас есть журналы, просмотрите их и
      1. Проверьте, имеет ли target.url недопустимый путь, и
      2. Посмотрите, сможете ли вы определить информацию о том, какая политика изменила target.url , чтобы он содержал неверный путь.

    API-прокси

    Проверка неисправного прокси-сервера API

    Если у вас нет трассировки или журналов этой ошибки, просмотрите неисправный прокси-сервер API, чтобы определить, что изменило или обновило переменную потока target.url , чтобы она содержала недопустимый путь. Проверьте следующее:

    • Политика в API-прокси
    • Любые общие потоки, вызываемые из прокси-сервера.
  5. Внимательно изучите конкретную политику (например: AssignMessage или JavaScript), которая изменяет или обновляет переменную потока target.url и определите причину обновления target.url , чтобы указать недопустимый путь.

    Вот несколько примеров политик, которые неправильно обновляют переменную потока target.url , чтобы она содержала недопустимый путь, приводящий к этой ошибке.

    Образец №1

    Пример № 1: Обновление политики JavaScript в переменной target.url

    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. Политика JavaScript обновляет переменную target.url на основе значения в заголовке запроса.

    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 переменной. url и значение другой переменной path , значение которой извлекается из request.header.Path .

    Если у вас есть доступ к фактическому запросу или трассировке, вы можете проверить фактическое значение, переданное в request.header.Path .

    Пример запроса, сделанного пользователем

    curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
    

    В этом примере путь заголовка не отправляется как часть запроса. Следовательно, значение переменной path в политике JavaScript равно null .

    Так:

    • url = https://mocktarget.apigee.net + path
    • url = https://mocktarget.apigee.net + "?user"
    • target.url = https://mocktarget.apigee.net?user

    Обратите внимание, что значение target.url состоит из следующих компонентов:

    • схема: https
    • Авторитет: mocktarget.apigee.net
    • путь: ?user

    Путь начинается с вопросительного знака ( ? ) вместо косой черты ( / ) , что является недопустимым . Следовательно, Apigee Edge возвращает 500 Internal Server Error с кодом ошибки protocol.http.BadPath .

    Образец №3

    Пример № 3. Обновление политики AssignMessage переменной target.url

    <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-адреса RFC 3986, раздел 3: Компоненты синтаксиса , компонент path является обязательным , и он ДОЛЖЕН всегда начинаться с «/» . Поэтому выполните следующие шаги, чтобы решить эту проблему:

  1. Убедитесь, что URL-адрес внутреннего сервера, представленный переменной потока target.url всегда имеет допустимый путь и всегда начинается с косой черты ( / ) .
    1. В некоторых случаях в пути может отсутствовать имя ресурса, поэтому убедитесь, что путь имеет хотя бы косую черту ( / ).
    2. Если вы используете какие-либо другие переменные для определения значения переменной потока target.url , убедитесь, что другие переменные не имеют недопустимый путь .
    3. Если вы выполняете какие-либо строковые операции для определения значения переменной потока target.url , убедитесь, что результат или результат строковых операций не имеет недопустимый путь .
  2. В примерах, рассмотренных выше, вы можете исправить эту проблему, как описано ниже:

    Образец №1

    Пример № 1: Обновление политики JavaScript в переменной target.url

    Используйте косую черту ( / ) вместо вопросительного знака ( ? ) в url переменной, чтобы устранить эту проблему, как показано ниже:

    var url = "https://mocktarget.apigee.net/json"
    context.setVariable("target.url", url);

    Образец №2

    Пример № 2. Политика JavaScript обновляет переменную target.url на основе значения в заголовке запроса.

    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: Политика AssignMessage обновляет переменную target.url

    Добавьте допустимый путь в элемент <Value> политики AssignMessage. То есть замените вопросительный знак ( ? ) с косая черта ( / ) в элементе <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 ожидает, что path компонент URL-адрес внутреннего сервера ДОЛЖЕН всегда начинаться с косая черта ( / ) согласно следующим спецификациям:

    Спецификация
    RFC 3986, раздел 3: Синтаксические компоненты
    RFC 3986, раздел 3.3: Путь

    Если вам по-прежнему нужна помощь со стороны службы поддержки Apigee, перейдите к разделу «Необходимо собрать диагностическую информацию» .

    Необходимо собрать диагностическую информацию

    Если проблема не устранена даже после выполнения приведенных выше инструкций, соберите следующую диагностическую информацию, а затем обратитесь в службу поддержки Apigee Edge :

    Если вы являетесь пользователем Public Cloud , предоставьте следующую информацию:

    • Название организации
    • Имя среды
    • Имя прокси API
    • Полная команда curl , используемая для воспроизведения 500 Internal Server Error с кодом ошибки protocol.http.BadPath
    • Файл трассировки запросов API

    Если вы являетесь пользователем частного облака , предоставьте следующую информацию:

    • Полное сообщение об ошибке, наблюдаемое для неудачных запросов
    • Имя среды
    • Пакет прокси API
    • Файл трассировки запросов API
    • Журналы доступа NGINX:

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

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

    • Системные журналы процессора сообщений /opt/apigee/var/log/edge-message- processor/logs/system.log

    Ссылки

    Переменные потока — цель