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

Ошибка 500: внутренняя ошибка сервера – потоковая передача включена

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

Symptom

Клиентское приложение получает код статуса HTTP-ответа 500 с сообщением Внутренняя ошибка сервера для вызовов API.

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

Клиентские приложения могут получить ответ об ошибке, как показано ниже:

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

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

Ошибка 500 (внутренняя ошибка сервера) может возникать по разным причинам. В этом руководстве рассматривается ошибка 500: внутренняя ошибка сервера, которая возникает при попытке доступа к полезной нагрузке запроса или ответа, когда включена потоковая передача.

Cause	Описание	Кто может выполнять инструкции по устранению неполадок
Доступ к полезной нагрузке при включенной потоковой передаче	Произошла ошибка, поскольку доступ к полезной нагрузке запроса или ответа осуществляется при включенной потоковой передаче.	Пользователи частного и общедоступного облака Edge

Причина: доступ к полезной нагрузке при включенной потоковой передаче

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

Процедура 1. Использование Trace

Включите сеанс трассировки и выполните вызов API, чтобы воспроизвести проблему – внутреннюю ошибку сервера 500.
Выберите один из неудачных запросов и изучите трассировку.
Перемещайтесь по разным этапам трассировки и найдите, где произошел сбой.
Эта ошибка могла произойти, когда правило обрабатывало полезную нагрузку запроса или ответа.
Ниже приведен пример скриншота трассировки, на котором показано, что политика JSONThreatProtection не работает и выдает ошибку "Expecting } at line 1":

Запишите следующую информацию из вывода трассировки, как показано на скриншоте выше:

Нарушение правил: JSONThreatProtection

Процесс: запрос прокси-сервера
Проверьте определение правил, которые не выполняются, и полезную нагрузку, которая обрабатывается.
В примере сценария изучите правило JSONThreatProtection с названием JSON-Threat-Protection, которое не удалось применить, и проверьте элемент <Source>.
```
<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>
```
Обратите внимание, что элемент <Source> указывает на request.. Это означает, что ошибка произошла при обработке полезной нагрузки запроса.
Определите тип полезной нагрузки, которая анализируется, проверив запрос к API.

Вы можете проверить содержимое полезной нагрузки запроса и заголовка Content-Type в запросе к API. В приведенной ниже команде curl используется полезная нагрузка JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Вы также можете проверить правила, которые не выполняются, и определить тип обрабатываемой полезной нагрузки. В приведенном выше примере сценария не выполняется правило JSON-Threat-Protection. Это означает, что полезная нагрузка должна быть в формате JSON.

Проверьте, соответствует ли полезная нагрузка правильному формату. Если полезная нагрузка недействительна, может появиться эта ошибка.

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

В зависимости от полезной нагрузки, которая анализируется правилом (как определено на шаге 6), изучите ее содержимое в инструменте Trace на соответствующем этапе.

В примере выполняется анализ полезной нагрузки запроса, поэтому изучите этап Request Received from Client (Запрос получен от клиента) в трассировке и проверьте Request Content (Содержимое запроса).

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

Это связано с тем, что при включенной потоковой передаче полезная нагрузка запроса не будет отображаться в трассировке.

Если ошибка возникает при анализе полезной нагрузки ответа, проверьте контент ответа на этапе Response received from target server (Ответ получен от целевого сервера).
Затем изучите определения прокси-сервера и целевой конечной точки в зависимости от того, где в потоке прокси-сервера API используется правило, которое не выполняется. Проверьте, включена ли трансляция.

В примере выше невыполненная политика была запущена в потоке запроса прокси-сервера (как определено на шаге 5 выше). Поэтому проверьте конечную точку прокси-сервера:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
Как видно из примера выше, потоковая передача запросов включена, поскольку для свойства "request.streaming.enabled" задано значение true.

Таким образом, причина ошибки – использование правила JSONThreatProtection в API Proxy, которое получает доступ к полезной нагрузке запроса, когда включена потоковая передача. Это приводит к ошибкам, поскольку запускает буферизацию в прокси API и сводит на нет преимущества потоковой передачи в Apigee Edge.

При использовании небольших полезных нагрузок эта ошибка может не возникать, но при использовании больших полезных нагрузок она может появиться.
Чтобы проверить, вызвана ли ошибка 500 правилом, посмотрите значение X-Apigee-fault-source на этапе AX (Записанные данные Аналитики) в трассировке, выполнив следующие действия:
1. Нажмите на "AX" (Analytics Data Recorded) Phase (Этап "AX" (Данные аналитики записаны)), как показано на скриншоте ниже.
2. Прокрутите страницу "Сведения об этапе" до раздела Заголовки ошибок и определите значения X-Apigee-fault-code, X-Apigee-fault-source и X-Apigee-fault-policy, как показано ниже:
3. Если значение X-Apigee-fault-source – policy, как показано на изображении выше, это означает, что ошибка вызвана правилом, которое обращается к полезной нагрузке при включенной потоковой передаче.

Разрешение

Доступ к полезной нагрузке при включенной потоковой передаче является антипаттерном, как описано в разделе Антипаттерн: доступ к полезной нагрузке запроса/ответа при включенной потоковой передаче.

Если вы хотите обработать полезную нагрузку, отключите потоковую передачу в конечной точке прокси-сервера или целевой конечной точке, удалив свойства "request.streaming.enabled" and "response.streaming.enabled", как показано в примере ProxyEndpoint ниже.
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
ИЛИ
Если вы хотите использовать потоковую передачу для прокси API, не используйте в нем правила, которые обращаются к полезной нагрузке запроса или ответа.

Примечания

В этом руководстве по использованию в примере сценария для обработки полезной нагрузки запроса с включенной потоковой передачей использовалось правило JSONThreatProtection. Это привело к внутренней ошибке сервера 500 с разными ошибками.
Эти ошибки также могут возникать при использовании правил, таких как JSONToXML и XMLToJSON, которые обрабатывают полезную нагрузку запроса или ответа при включенной потоковой передаче.
Мы настоятельно рекомендуем не использовать такие правила в прокси, которым требуется доступ к полезной нагрузке при включенной потоковой передаче.
Это антипаттерн, как описано в разделе Антипаттерн: доступ к полезной нагрузке запроса/ответа при включенной потоковой передаче.

Как диагностировать проблемы с помощью мониторинга API

Если вы используете частное облако, пропустите эту процедуру.

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

Пошаговое руководство по устранению ошибок 5xx в API с помощью API Monitoring. Например, вы можете настроить оповещение, которое будет срабатывать, когда количество ошибок 500 превысит определенный порог.

Если вы хотите получать уведомления о том, что правила возвращают ответ с ошибкой 500, настройте оповещение для кода статуса 500, указав в качестве источника ошибки значение Прокси.

Обязательная диагностическая информация

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

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

Название организации
Название среды
Название прокси API
Полная команда curl вместе с полезной нагрузкой запроса (если есть), чтобы воспроизвести ошибку 500
Файл трассировки, содержащий запросы с внутренней ошибкой сервера 500
Если ошибки 500 не возникают в данный момент, укажите период времени и часовой пояс, когда они происходили в прошлом.

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

Полное сообщение об ошибке, которое появляется при неудачных запросах.
Название организации, среды и прокси API, для которых вы наблюдаете ошибки 500.
Пакет прокси API
Полезная нагрузка, использованная в запросе (если есть).
Файл трассировки, содержащий запросы с внутренней ошибкой сервера 500
Журналы доступа NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Журналы Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Период времени с информацией о часовом поясе, когда произошли ошибки 500.