502 Bad Gateway - ResponseWithBody

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

Symptom

Клиентское приложение получает код статуса HTTP 502 Bad Gateway с кодом ошибки protocol.http.ResponseWithBody в качестве ответа на вызовы API.

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

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

HTTP/1.1 502 Bad Gateway

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

{
   "fault":{
      "faultstring":"Received 204 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

{
   "fault":{
      "faultstring":"Received 205 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

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

Эта ошибка возникает, если HTTP-ответ от внутреннего сервера к Apigee Edge имеет код 204 No Content или 205 Reset Content, но содержит тело ответа и/или один или несколько из следующих заголовков:

• Content-Length
• Content-Encoding
• Transfer-Encoding

Согласно спецификациям RFC 7231, раздел 6.3.5: 204 No Content и RFC 7231, раздел 6.3.6: 205 Reset Content, ожидается, что сервер-источник не будет отправлять дополнительный контент в теле полезной нагрузки ответа с кодом статуса 204 No Content или 205 Reset Content. Заголовки ответа, например Content-Length, Content-Encoding или Transfer-Encoding, указывают размер, тип или формат полезной нагрузки ответа.

Поэтому Apigee Edge возвращает клиенту код статуса 502 Bad Gateway с кодом ошибки protocol.http.ResponseWithBody в следующих случаях:

Вот возможные причины этой ошибки:

Распространенные этапы диагностики

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

Причина: тело ответа или заголовки с ответом 204 от внутреннего сервера

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

1. Определите код ошибки и источник ошибки, используя мониторинг API, инструмент трассировки или журналы доступа NGINX, как описано в разделе Распространенные этапы диагностики.
2. Если код ошибки – protocol.http.ResponseWithBody, а источник ошибки – target, это означает, что сервер отправил код статуса 204 No Content или 205 Reset Content с текстом ответа и/или одним из заголовков, упомянутых в разделе Возможные причины.

3. Чтобы проверить, действительно ли бэкенд-сервер отправил тело полезной нагрузки ответа и/или один или несколько заголовков, упомянутых в разделе Возможные причины, выполните следующие действия:

   1. Если вы используете общедоступное облако и можете отправлять тот же запрос к API на серверную часть напрямую из любой из своих систем.

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

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

      Пример 1

      Пример 1. Ответ внутреннего сервера 204 с заголовком Content-Encoding

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Encoding: gzip
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      В этом примере внутренний сервер ответил кодом статуса 204 No Content и заголовком Content-Encoding: gzip.

      Пример 2

      Пример 2. Ответ сервера 204 с заголовком Content-Length

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Length: 48
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      В этом примере внутренний сервер ответил кодом статуса 204 No Content и заголовком Content-Length: 48.

      Пример 3

      Пример 3. Ответ внутреннего сервера 205 с телом ответа

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 205 Reset Content
      < Date: Sat, 31 Jul 2021 17:14:09 GMT
      < Content-Length: 12
      < Content-Type: text/plain; charset=utf-8
      <
      * Connection #0 to host X.X.X.X left intact
      This is a sample Response
      

      В этом примере внутренний сервер ответил кодом статуса 205 Reset Content с телом ответа This is a sample Response..

   4. Во всех приведенных выше примерах сервер отправил код статуса 204 No Content или 205 Reset Content с телом ответа и/или одним из заголовков, упомянутых в разделе Возможные причины.
   5. Поэтому Apigee Edge отправил код статуса 502 Bad Gateway с кодом ошибки protocol.http.ResponseWithBody.

Разрешение

Убедитесь, что при отправке ответа 204 No Content или 205 Reset Content в Apigee Edge сервер всегда соответствует спецификации RFC 7231, раздел 6.3.6: 205 Reset Content. Это означает, что серверная часть НЕ ДОЛЖНА отправлять следующие данные в составе ответа 204 No Content или 205 Reset Content:

1. Тело полезной нагрузки ответа
2. и любой из следующих заголовков:
   1. Content-Length
   2. Content-Encoding
   3. Transfer-Encoding

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

Apigee Edge отвечает кодом статуса 502 Bad Gateway и кодом ошибки protocol.http.ResponseWithBody, если серверный сервис отправляет ответ 204 No Content или 205 Reset Content, но не соответствует следующим спецификациям RFC:

Важная информация

Рекомендуем настроить сервер так, чтобы он отправлял коды статуса 204 No Content и 205 Reset Content без тела ответа и заголовков Content-Length, Content-Encoding и Transfer-Encoding, а также соблюдал спецификации RFC 7231, раздел 6.3.5: 204 No Content и RFC 7231, раздел 6.3.6: 205 Reset Content.

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

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

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

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

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

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

• Полное сообщение об ошибке, которое появляется при неудачных запросах.
• Название среды
• Пакет прокси API
• Файл трассировки для запросов к API

• Журналы доступа NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

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

• Системные журналы Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log