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

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

Симптом

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

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

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

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Request path cannot be empty",
      "detail":{
         "errorcode":"protocol.http.EmptyPath"
      }
   }
}

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

Эта ошибка возникает, если URL-адрес запроса к бэкэнд-серверу, представленный переменной потока target.url , содержит пустой путь.

В соответствии со спецификациями 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.EmptyPath .

Например: если target.url имеет значение https://www.mocktarget.apigee.net , то возникает следующая ошибка, связанная с path Компонент пуст или отсутствует.

Причина Описание Инструкции по устранению неполадок, применимые для
URL бэкэнд-сервера (target.url) содержит пустой путь. URL-адрес бэкэнд-сервера, представленный переменной потока target.url , содержит пустой путь. Пользователи публичных и частных облачных сервисов на периферии сети

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

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

Мониторинг API

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

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

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

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

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

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

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

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

След

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

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

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

  3. Выберите один из запросов, завершившихся неудачей, и изучите трассировку.
  4. Проследите за различными этапами трассировки и определите место возникновения сбоя.
  5. Как правило, ошибка возникает после этапа «Начало выполнения целевого запроса» , как показано ниже:

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

    Ошибка: путь запроса не может быть пустым.

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

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

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

    В приведенном выше примере трассировки обратите внимание на значение переменной потока target.url Обновление происходит в политике JavaScript под названием SetTargetURL следующим образом:

    target.url : https://mocktarget.apigee.net
  9. Обратите внимание, что target.url состоит из следующих компонентов:
    • Схема: https://mocktarget.apigee.net
    • путь: пустой
  10. Поэтому вы получаете ошибку " Request path cannot be empty .
  11. Перейдите к этапу AX (Analytics Data Recorded) в трассировке и щелкните по нему.
  12. Прокрутите вниз до раздела «Подробности этапаЗаголовки ошибок» и определите значения X-Apigee-fault-code и X-Apigee-fault-source, как показано ниже:

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

NGINX

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

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

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

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

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

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

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

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

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

Причина: URL-адрес бэкэнд-сервера (target.url) содержит пустой путь.

Диагноз

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

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

    След

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

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

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

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

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

    Журналы

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

    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: Обновление переменной target.url в соответствии с политикой JavaScript

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

    В приведенном выше примере обратите внимание, что переменная потока target.url обновляется значением https://mocktarget.apigee.net , содержащимся в другой переменной url .

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

    • Схема: https://mocktarget.apigee.net
    • путь: пустой

    Поскольку путь пуст, Apigee Edge возвращает 500 Internal Server Error с кодом ошибки protocol.http.EmptyPath .

    Образец №2

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

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

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

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

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

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

    Так:

    • url = https://mocktarget.apigee.net + path
    • url = https://mocktarget.apigee.net + null
    • target.url = https://mocktarget.apigee.netnull

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

    • схема: https://mocktarget.apigee.netnull
    • путь: пустой

    Образец №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</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>

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

    • Схема: https://mocktarget.apigee.net
    • путь: пустой

    Во всех приведенных выше примерах путь в URL-адресе бэкэнд-сервера, то есть target.url , пуст, поэтому Apigee Edge возвращает 500 Internal Server Error с кодом ошибки protocol.http.EmptyPath .

Разрешение

В соответствии со спецификацией RFC 3986, раздел 2: Компоненты синтаксиса , компонент path является обязательным и ДОЛЖЕН всегда содержать косую черту (/), даже если в path нет других символов. Для решения этой проблемы выполните следующие действия:

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

    Образец №1

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

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

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

    Образец №2

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

    var path = context.getVariable("request.header.Path");
    var url = "https://mocktarget.apigee.net" + path
    context.setVariable("target.url", url);

    Чтобы исправить эту проблему, убедитесь, что вы передаете допустимый путь, например, /iloveapis в заголовке запроса Path как показано ниже:

    Пример запроса:

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

    Образец №3

    Пример №3: Политика AssignMessage обновляет переменную target.url через другую переменную.

    Добавьте допустимый путь в элемент <Value> политики AssignMessage. Например, это может быть /json в качестве пути к API MockTarget . То есть, измените элемент <Value> на https://mocktarget.apigee.net/json как показано ниже:

    <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
        <DisplayName>AM-SetTargetURL</DisplayName>
        <AssignVariable>
             <Name>target.url</Name>
             <Value>https://mocktarget.apigee.net/json</Value>
        </AssignVariable>
        <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
        <AssignTo createNew="false" transport="http" type="request"/>
    </AssignMessage>

Спецификация

Apigee Edge ожидает, что URL-адрес бэкэнд-сервера не будет содержать пустой путь в соответствии со следующими спецификациями:

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

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

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

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

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

  • Название организации
  • Название среды
  • Имя API-прокси
  • Полная команда curl , использованная для воспроизведения 500 Internal Server Error с кодом ошибки protocol.http.EmptyPath
  • Файл трассировки для запросов 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

Ссылки

Переменные потока - целевые значения