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

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

Симптом

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

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

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

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. Проверить, был ли запрос от клиента отправлен в сжатом формате и превысил ли размер несжатого файла допустимый лимит, можно одним из следующих способов:

   След

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

   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 в http.properties установлено со значением 10m .

   Это означает, что ограничение на размер полезной нагрузки запроса, настроенное в Apigee for Private Cloud, составляет 10 МБ.

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

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

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

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

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

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

• Полное сообщение об ошибке, полученное для неудачных запросов.
• Название организации
• Название среды
• Пакет API-прокси
• Файл трассировки для неудачных запросов API
• Полная команда curl, использованная для воспроизведения ошибки 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