413 Слишком большой объект запроса — TooBigBody

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

Симптом

Клиентское приложение получает код состояния HTTP 413 Request Entity Too Large с кодом ошибки protocol.http.TooBigBody в качестве ответа на вызовы API.

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

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

HTTP/1.1 413 Request Entity Too Large

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

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

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

Эта ошибка возникает, если размер полезных данных, отправленных клиентским приложением в Apigee Edge как часть HTTP-запроса, превышает допустимый предел в Apigee Edge .

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

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

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

Причина: Размер полезной нагрузки запроса превышает допустимый предел.

Диагностика

1. Определите код ошибки , источник ошибки и размер полезной нагрузки запроса для обнаруженной ошибки с помощью мониторинга API, инструмента трассировки или журналов доступа NGINX, как описано в разделе «Общие шаги диагностики для сценария № 1» (несжатого).
2. Если источник сбоя имеет policy значений или proxy , это означает, что размер полезных данных запроса, отправленный клиентским приложением в Apigee, превышает допустимый предел в Apigee Edge .
3. Проверьте размер полезной нагрузки запроса , определенный на шаге №1.
   • Если размер полезных данных превышает допустимый предел 10 МБ, это и есть причина ошибки.
   • Если размер полезных данных < допустимого предела 10 МБ, возможно, полезные данные запроса передаются в сжатом формате. Перейти к причине: размер полезных данных запроса превышает допустимый предел после распаковки
4. Вы также можете проверить, действительно ли размер полезных данных запроса превышает допустимый предел в 10 МБ, проверив фактический запрос, выполнив следующие действия:
   1. Если у вас нет доступа к фактическому запросу, сделанному клиентским приложением, перейдите к разделу «Разрешение» .
   2. Если у вас есть доступ к фактическому запросу, сделанному клиентским приложением, выполните следующие действия:
      1. Проверьте размер полезных данных, переданных в запросе.
      2. Если вы обнаружите, что размер полезных данных превышает допустимый предел в Apigee Edge , то это и есть причина проблемы.

      Образец запроса:

      curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v
      

      В приведенном выше случае файл test15mbfile занимает ~15 МБ. Если вы используете какой-либо другой клиент, получите журналы клиента, чтобы узнать размер отправляемой полезной нагрузки.

Разрешение

Перейдите в раздел «Решение» .

Причина: Размер полезной нагрузки запроса превышает допустимый предел после распаковки.

Если полезные данные запроса отправляются в сжатом формате , а для заголовка запроса Content-Encoding установлено значение gzip , Apigee распаковывает полезные данные запроса. Если во время процесса распаковки Apigee обнаруживает, что размер полезных данных превышает допустимый предел 10 МБ, он прекращает дальнейшую распаковку и немедленно отвечает 413 Request Entity Too Large с кодом ошибки protocol.http.TooBigBody .

Диагностика

1. Определите код неисправности, источник неисправности , и запросите размер полезной нагрузки для ошибки, обнаруженной с помощью журналов мониторинга API, инструмента трассировки или доступа NGINX, как описано в разделе «Общие шаги диагностики для сценария № 2» (сжатого).
2. Если источник сбоя имеет policy значений или proxy , это означает, что размер полезных данных запроса, отправленный клиентским приложением в Apigee, превышает разрешенный предел в Apigee Edge.
3. Проверьте размер полезной нагрузки запроса , определенный на шаге 1 .
   • Если размер полезных данных превышает допустимый предел 10 МБ, это и есть причина ошибки.
   • Если размер полезных данных < допустимого предела 10 МБ, возможно, полезные данные запроса передаются в сжатом формате. В этом случае проверьте несжатый размер сжатых полезных данных запроса.
4. Вы можете проверить, был ли запрос от клиента отправлен в сжатом формате и размер несжатого файла превышал допустимый предел, используя один из следующих методов:

   След

   Чтобы проверить с помощью инструмента «Трассировка»:

   1. Если вы зафиксировали трассировку неудачного запроса, обратитесь к шагам, подробно описанным в разделе Трассировка и
      1. Определите значение переменной client.received.content.length .
      2. Проверьте, содержит ли запрос от клиента заголовок Content-Encoding: gzip .
   2. Если значение переменной client.received.content.length превышает 10 МБ, разрешенный предел и заголовок запроса Content-Encoding: gzip , то это и есть причина этой ошибки.

   Фактический запрос

   Чтобы подтвердить использование фактического запроса:

   1. Если у вас нет доступа к фактическому запросу, сделанному клиентским приложением, перейдите к разделу «Разрешение» .
   2. Если у вас есть доступ к фактическому запросу, сделанному клиентским приложением, выполните следующие действия:
      1. Проверьте размер полезных данных, переданных в запросе вместе с заголовком Content-Encoding , отправленным в запросе.

      2. Проверьте, превышает ли размер несжатой полезной нагрузки разрешенный предел в Apigee Edge.

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

         curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
         

         В приведенном выше случае размер файла test15mbfile.gz меньше предельного размера; однако размер несжатого файла test15mbfile составляет ~15 МБ, а заголовок Content-Encoding — gzip .

         Если вы используете какой-либо другой клиент, получите журналы клиента, чтобы узнать размер отправляемой полезной нагрузки и установлено ли для заголовка Content-Encoding значение gzip .

   Журналы процессора сообщений

   Для проверки с использованием журналов процессора сообщений:

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

   2. Проверьте журналы процессора сообщений:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. Выполните поиск, чтобы узнать, возникли ли какие-либо ошибки 413 в течение определенного периода времени (если проблема возникла в прошлом) или есть ли какие-либо запросы, которые по-прежнему не выполняются с 413 .

      Вы можете использовать следующие строки поиска:

      grep -ri "chunkCount"
      

      grep -ri "RequestTooLarge"
      

   4. Вы найдете строки из system.log похожие на следующие ( TotalRead и chunkCount могут отличаться в вашем случае):

      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
        TrackingInputChannel.checkMessageBodyTooLarge()
        : Message is too large.  TotalRead 10489856 chunkCount 2570
      
      2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
        ExceptionHandler.handleException()
        : Exception trace: com.apigee.errors.http.user.RequestTooLarge
        : Body buffer overflow

   5. Как только в процессе распаковки процессор сообщений определяет, что общее количество прочитанных байт > 10 МБ, он останавливается и печатает следующую строку:

      Message is too large.  TotalRead 10489856 chunkCount 2570

      Это означает, что размер полезной нагрузки запроса превышает 10 МБ, и Apigee выдает ошибку RequestTooLarge , когда размер начинает превышать предел в 10 МБ с кодом ошибки в качестве protocol.http.TooBigBody

Разрешение

Пределы

Apigee ожидает, что клиентское приложение и внутренний сервер не будут отправлять размеры полезной нагрузки, превышающие разрешенный предел, как указано для Request/response size в Apigee Edge Limits .

1. Если вы являетесь пользователем публичного облака , то максимальный предел размера полезной нагрузки запроса и ответа соответствует Request/response size указанному в Apigee Edge Limits .
2. Если вы являетесь пользователем частного облака, возможно, вы изменили ограничение по умолчанию для размера полезной нагрузки запроса и ответа (хотя это не рекомендуется). Вы можете определить максимальный размер полезных данных запроса, следуя инструкциям в разделе Как проверить текущий предел .

Как проверить текущий лимит?

В этом разделе объясняется, как проверить, что свойство HTTPRequest.body.buffer.limit обновлено новым значением в процессорах сообщений.

1. На компьютере с процессором сообщений найдите свойство HTTPRequest.body.buffer.limit в каталоге /opt/apigee/edge-message- processor/conf и проверьте, какое значение было установлено с помощью следующей команды:

   grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. Пример результата выполнения приведенной выше команды выглядит следующим образом:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

3. Обратите внимание, что в приведенном выше примере для свойства HTTPRequest.body.buffer.limit установлено значение 10m в http.properties .

   Это указывает на то, что ограничение размера полезных данных запроса, настроенное в Apigee для частного облака, составляет 10 МБ.

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

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

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

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

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

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

• Полное сообщение об ошибке, наблюдаемое для неудачных запросов
• Название организации
• Имя среды
• Пакет API-прокси
• Файл трассировки неудачных запросов API
• Полная команда завитка, используемая для воспроизведения ошибки 413

• Журналы доступа 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