Неизвестная ошибка на панели "Попробовать этот API"

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

Symptom

Вызов API из интегрированного портала для разработчиков завершается неудачно с ошибкой Unknown Error или пустым ответом на панели Попробовать API.

Сообщения об ошибках

В интегрированном портале для запросов API может появиться пустой ответ или следующее сообщение об ошибке:

Unknown Error

На вкладке Инструменты разработчика > Консоль вы увидите следующую ошибку:

Access to XMLHTTPRequest at 'API_URL' from origin 'URL_of_Integrated_DevPortal'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is
present on the requested resource.

Общее сообщение об ошибке, которое можно увидеть на вкладке Инструменты разработчика > Консоль, выглядит следующим образом:

стандартное сообщение об ошибке (нажмите, чтобы увеличить изображение); стандартное сообщение об ошибке;

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

Причина Описание Инструкции по устранению неполадок, применимые к
Необработанная ошибка правил Ответ об ошибке по умолчанию отправляется без заголовков CORS, если в процессе выполнения запроса к API не удается применить какое-либо правило. Пользователи Edge Public Cloud
Несколько значений для Access-Control-Allow-Origin Использование команды Add вместо Set в правиле "Назначить правила для сообщений". Пользователи Edge Public Cloud

Причина: необработанная ошибка правил

диагностика;

  1. Убедитесь, что проблема возникает только в том случае, если ожидается ответ, отличный от 2XX.
  2. Если запросы не выполняются, убедитесь, что в потоке прокси-сервера есть правила.
  3. Отследите запрос и проверьте, не нарушает ли политика с continueOnError="false" правила и не вызывает ли ошибку.
    1. Если да, проверьте, был ли выполнен в потоке ответов об ошибках.
    2. Если нет, то это и есть причина проблемы.
      Это связано с тем, что при нарушении любого правила с элементом continueOnError="false" запрос переходит к обработке ответа с ошибкой. Если в потоке ответов об ошибках не предусмотрена явная обработка ошибок, то отправляется ответ об ошибке по умолчанию, соответствующий правилу. В этом ответе об ошибке нет заголовков CORS. В результате вызов API из интегрированного портала разработчика завершается с ошибкой Unknown error.

На скриншотах ниже показаны примеры сообщений об ошибке и успешном выполнении операции.

Пример сообщения об ошибке на панели Попробовать этот API встроенного портала и в окне Трассировка прокси:

Пример сообщения об ошибке (нажмите, чтобы увеличить изображение) Пример сообщения об ошибке

Пример сообщения об успешном выполнении на панели Попробовать этот API встроенного портала и в окне Трассировка прокси:

Пример сообщения об успешном выполнении. Нажмите на изображение, чтобы увеличить его. пример сообщения об успешном выполнении;

Разрешение

  1. Вместо того чтобы полагаться на сообщение об ошибке по умолчанию, необходимо реализовать правило обработки ошибок. Добавьте правило AssignMessage CORS с подходящими заголовками и вызовите его в правиле FaultRule.
  2. Иногда невозможно определить правило для каждой ошибки, поэтому можно реализовать правило по умолчанию, чтобы выполнить политику CORS AssignMessage:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="proxy-endpoint-name">
    <Description/>
    <!-- Add a default fault rule to add CORS -->
    <DefaultFaultRule name="fault-rule">
        <Step>
            <Name>add-cors</Name>
        </Step>
    </DefaultFaultRule>
    <FaultRules/>
    <!--
    <Flows />
    Rest of the proxy definition
    -->
</ProxyEndpoint>

Причина: несколько значений для Access-Control-Allow-Origin

диагностика;

  1. Проверьте значение заголовка Access-Control-Allow-Origin в сеансе трассировки.
  2. Заголовок Access-Control-Allow-Origin позволяет задать только одно значение. Если задать несколько значений, может возникнуть проблема с технологией CORS, и портал для разработчиков не сможет обработать ответы.
  3. Если значение заголовка Access-Control-Allow-Origin в трассировке выглядит как
    *,*
    , это означает, что его задают и целевой сервер, и правило CORS AssignMessage.
  4. Это может произойти, если пользователь использовал <Add> element для Access-Control-Allow-Origin в правиле или если серверная часть сама задает несколько значений.

Пример Access-Control-Allow-Origin, равный *,*:

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

Пример Access-Control-Allow-Origin, равный *:

Пример использования одного значения. Нажмите, чтобы увеличить изображение. пример использования одного значения;

Пример использования <Add>:

Пример использования функции &quot;Добавить&quot; (нажмите на изображение, чтобы увеличить его) Пример использования функции Add

Пример использования <Set>:

Пример использования функции &quot;Набор&quot;. Нажмите на изображение, чтобы увеличить его. Пример использования Set

Разрешение

  1. Рекомендуется использовать <Set> element (вместо <Add> element) для Access-Control-Allow-Origin, поскольку допускается только одно значение.
  2. Вы также можете задать заголовок Access-Control-Allow-Origin только в одном месте: в правиле CORS AssignMessage или на целевом сервере.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" name="set-cors">
    <DisplayName>Set CORS</DisplayName>
    <FaultRules/>
    <Properties/>
    <Set>
        <Headers>
            <Header name="Access-Control-Allow-Origin">*</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="response"/>
</AssignMessage>

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

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

Соберите указанную ниже диагностическую информацию и обратитесь в службу поддержки Apigee Edge:

  • Название организации
  • Название среды
  • Название прокси API
  • Полная команда curl, использованная для воспроизведения ошибки
  • Файл трассировки для запросов к API
  • Полный вывод ответа от целевого или внутреннего сервера, а также размер полезной нагрузки.