413 Entidade de solicitação muito grande - TooBigBody

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de status HTTP 413 Request Entity Too Large com o código de erro protocol.http.TooBigBody como resposta para chamadas de API.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta: 

HTTP/1.1 413 Request Entity Too Large

Além disso, você pode receber a seguinte mensagem de erro: 

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

Causas possíveis

Esse erro ocorre se o tamanho do payload enviado pelo aplicativo cliente para o Apigee Edge como parte da solicitação HTTP for maior que o limite permitido no Apigee Edge .

Confira as possíveis causas para esse erro :

Causa Descrição Instruções de solução de problemas aplicáveis para
O tamanho do payload da solicitação é maior do que o limite permitido O tamanho do payload enviado pelo aplicativo cliente como parte da solicitação HTTP para o Apigee Edge é maior que o limite permitido no Apigee Edge. Usuários da nuvem pública e privada do Edge
O tamanho do payload da solicitação excede o limite permitido após a descompactação O tamanho do payload enviado em formato compactado pelo aplicativo cliente como parte da solicitação HTTP para o Apigee Edge é maior que o limite permitido quando descompactado pelo Apigee Edge. Usuários da nuvem pública e privada do Edge

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

Monitoramento de APIs

Para diagnosticar o erro usando o API Monitoring:

  1. Faça login na interface do Apigee Edge como um usuário com um papel adequado.

  2. Mude para a organização em que você quer investigar o problema.

  3. Acesse a página Analisar > Monitoramento de APIs > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Selecione o filtro Proxy para restringir o código de falha.
  6. Crie um gráfico com Código de falha e Tempo.

  7. Selecione uma célula com o Código de falha protocol.http.TooBigBody e o Código de status 413, conforme mostrado abaixo:

  8. As informações sobre o código de falha protocol.http.TooBigBody são mostradas como abaixo:

  9. Clique em Ver registros e expanda a linha da solicitação com falha. Em seguida, na janela Registros, observe os detalhes conforme mostrado abaixo :

    Não compactado

    Cenário 1: payload da solicitação enviado sem compactação

    Na janela "Registros", observe os seguintes detalhes:

    • Código de status:413
    • Origem da falha:proxy
    • Código de falha:protocol.http.TooBigBody.
    • Comprimento da solicitação(bytes): 15360440 (~15 MB)

    Se a Origem da falha tiver o valor proxy, o Código da falha terá o valor protocol.http.TooBigBody e o Comprimento da solicitação será maior que 10 MB. Isso indica que a solicitação HTTP do cliente tem um tamanho de payload maior que o limite permitido na Apigee.

    Compactado

    Cenário 2: payload da solicitação enviado de forma compactada

    Na janela Registros, observe os seguintes detalhes:

    • Código de status:413
    • Origem da falha:proxy
    • Código de falha:protocol.http.TooBigBody.
    • Comprimento da solicitação(bytes): 15264 (~15 kB)

    Se a Origem da falha tiver o valor proxy, o Código da falha terá o valor protocol.http.TooBigBody e o Comprimento da solicitação será menor que 10 MB. Isso indica que a solicitação HTTP do cliente tem um tamanho de payload menor que o limite permitido no formato compactado, mas o tamanho do payload é maior que o limite permitido quando descompactado pela Apigee.

Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e uma das seguintes opções:
    • Aguarde o erro 413 Request Entity Too Large ocorrer ou
    • Se for possível reproduzir o problema, faça a chamada de API e reproduza o erro 413 Request Entity Too Large.

  2. Verifique se a opção Mostrar todas as informações de fluxo está ativada.

  3. Selecione uma das solicitações com falha e examine o rastreamento.
  4. Acesse a fase Solicitação recebida do cliente.

    Não compactado

    Cenário 1: payload da solicitação enviado sem compactação

    Observações:

    • Content-Encoding:não presente
    • Content-Length:15360204

    Compactado

    Cenário 2: payload da solicitação enviado de forma compactada

    Observações:

    • Content-Encoding:gzip
    • Content-Length:14969
    • Content-Type:application/x-gzip
  5. Navegue pelas diferentes fases do rastreamento e localize onde a falha ocorreu.

  6. Normalmente, o erro aparece em um fluxo após a fase Solicitação recebida do cliente, conforme mostrado abaixo:

  7. Anote o valor do erro no rastreamento. O trace de exemplo acima mostra:
    • Erro:Body buffer overflow
    • error.class::com.apigee.errors.http.user.RequestTooLarge

  8. Acesse Resposta enviada ao cliente e observe os valores do erro no rastreamento. O trace de amostra abaixo mostra:

    • Erro:413 Request Entity Too Large
    • Conteúdo do erro: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. Navegue até a fase AX (dados do Analytics registrados) no rastreamento e clique nela.

  10. Na seção Detalhes da fase, role a tela para baixo até Variáveis lidas.

  11. Determine o valor da variável client.received.content.length , que indica:
    • O tamanho real do payload da solicitação quando ele é enviado em formato não compactado e
    • O tamanho do payload de solicitação após a descompactação pela Apigee, quando o payload é enviado em formato compactado. Ele sempre será o mesmo que o valor do limite permitido (10 MB) neste cenário.

    Não compactado

    Cenário 1: payload da solicitação sem compactação

    Variável client.received.content.length: 15360204

    Compactado

    Cenário 2: payload de solicitação em formato compactado

    Variável client.received.content.length: 10489856

  12. A tabela a seguir explica por que o erro 413 é retornado pela Apigee nos dois cenários com base no valor da variável client.received.content.length:
    Cenário Valor de client.received.content.length Motivo da falha
    Solicitar payload em formato não compactado ~15 MB O tamanho excede o limite permitido de 10 MB.
    Solicitar payload em formato compactado ~10 MB

    O limite de tamanho foi excedido após a descompactação

NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

  1. Se você for um usuário do Cloud privado, use os registros de acesso do NGINX para determinar as principais informações sobre erros HTTP 413.

  2. Verifique os registros de acesso do NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Pesquise para ver se há erros de 413 durante um período específico (se o problema aconteceu no passado) ou se ainda há solicitações com falha em 413.
  4. Se você encontrar erros de 413 com o X-Apigee-fault-code correspondente ao valor de protocol.http.TooBigBody, determine o valor de X-Apigee-fault-source.

    Não compactado

    Cenário 1 : tamanho do payload da solicitação em formato não compactado

    A entrada de exemplo acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-source:

    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Observe o Comprimento da solicitação:15360440 (14,6 MB > limite permitido)

    Compactado

    Cenário 2 : tamanho do payload da solicitação em formato compactado

    A entrada de exemplo acima do registro de acesso do NGINX tem os seguintes valores para X-Apigee-fault-code e X-Apigee-fault-source:

    Cabeçalhos de resposta Valor
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    Observe o tamanho da solicitação:15264 (14,9 K < limite permitido)

    Nesse cenário, o Apigee Edge retorna 413 mesmo que o comprimento da solicitação seja menor que o limite permitido, porque a solicitação pode ter sido enviada em formato compactado, e o tamanho do payload excede o limite após a descompactação pelo Apigee Edge.

Causa: o tamanho do payload da solicitação é maior que o limite permitido

Diagnóstico

  1. Determine o código de falha, a origem da falha e o tamanho da carga útil da solicitação do erro observado usando o API Monitoring, a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico com o cenário 1 (sem compactação).
  2. Se a Origem da falha tiver o valor policy ou proxy, isso indicará que o tamanho do payload da solicitação enviado pelo aplicativo cliente para a Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da solicitação, conforme determinado na etapa 1.
  4. Você também pode validar se o tamanho da carga útil da solicitação é realmente maior que o limite permitido de 10 MB verificando a solicitação real seguindo estas etapas:
    1. Se você não tiver acesso à solicitação real feita pelo aplicativo cliente, acesse Resolução.
    2. Se você tiver acesso à solicitação real feita pelo aplicativo cliente, siga estas etapas:
      1. Verifique o tamanho do payload transmitido na solicitação.
      2. Se você descobrir que o tamanho do payload é maior que o limite permitido no Apigee Edge, essa é a causa do problema.

        3. Exemplo de solicitação:

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

        No caso acima, o arquivo test15mbfile tem cerca de 15 MB. Se você estiver usando outro cliente, extraia os registros dele para descobrir o tamanho do payload enviado.

Resolução

Acesse Resolução.

Causa: o tamanho do payload da solicitação excede o limite permitido após a descompactação

Se o payload da solicitação for enviado em formato compactado e o cabeçalho da solicitação Content-Encoding estiver definido como gzip, , a Apigee vai descompactar o payload da solicitação. Durante o processo de descompactação, se a Apigee detectar que o tamanho do payload é maior que 10 MB, o limite permitido, ela interrompe a descompactação e responde imediatamente com 413 Request Entity Too Large e o código de erro protocol.http.TooBigBody.

Diagnóstico

  1. Determine o código de falha, a origem da falha e o tamanho do payload da solicitação do erro observado usando o API Monitoring, a ferramenta de rastreamento ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico com o cenário 2 (compactado).
  2. Se a Origem da falha tiver o valor policy ou proxy, isso indica que o tamanho do payload da solicitação enviado pelo aplicativo cliente para a Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da solicitação, conforme determinado na etapa 1.
    • Se o tamanho do payload for maior que o limite permitido de 10 MB, essa é a causa do erro.
    • Se o tamanho do payload for menor que o limite permitido de 10 MB, é possível que o payload da solicitação seja transmitido em formato compactado. Nesse caso, verifique o tamanho descompactado do payload de solicitação compactado.
  4. É possível validar se a solicitação do cliente foi enviada em formato compactado e se o tamanho não compactado era maior que o limite permitido usando um dos seguintes métodos:

    Trace

    Para validar usando a ferramenta Trace:

    1. Se você capturou um trace para a solicitação com falha, consulte as etapas detalhadas em Trace e
      1. Determine o valor da variável client.received.content.length
      2. Verifique se a solicitação do cliente continha o cabeçalho Content-Encoding: gzip
    2. Se o valor da variável client.received.content.length for maior que 10 MB, o limite permitido, e o cabeçalho da solicitação Content-Encoding: gzip, essa é a causa do erro.

    Solicitação real

    Para validar usando a solicitação real:

    1. Se você não tiver acesso à solicitação real feita pelo aplicativo cliente, acesse Resolução.
    2. Se você tiver acesso à solicitação real feita pelo aplicativo cliente, siga estas etapas:
      1. Verifique o tamanho do payload transmitido na solicitação junto com o cabeçalho Content-Encoding enviado na solicitação.

      2. Verifique se o tamanho descompactado do payload é maior que o limite permitido no Apigee Edge.

        Exemplo de solicitação:

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

        No caso acima, o arquivo test15mbfile.gz é menor que o limite de tamanho. No entanto, o tamanho do arquivo não compactado test15mbfile é de aproximadamente 15 MB, e o cabeçalho Content-Encoding é gzip.

        Se você estiver usando outro cliente, extraia os registros dele para descobrir o tamanho do payload enviado e se o cabeçalho Content-Encoding está definido como gzip.

    Registros do processador de mensagens

    Para validar usando registros do processador de mensagens:

    1. Se você for um usuário da nuvem privada, poderá usar os registros do processador de mensagens para determinar as principais informações sobre erros de HTTP 413.

    2. Verifique os registros do processador de mensagens:

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

    3. Pesquise para ver se há erros de 413 durante um período específico (se o problema aconteceu no passado) ou se ainda há solicitações com falha de 413.

      Você pode usar as seguintes strings de pesquisa:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Você vai encontrar linhas de system.log semelhantes às seguintes (TotalRead e chunkCount podem variar no seu caso): 
      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. Durante o processo de descompactação, assim que o processador de mensagens determina que o total de bytes lidos é > 10 MB, ele para e imprime a seguinte linha: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Isso significa que o tamanho do payload da solicitação é maior que 10 MB, e a Apigee gera o erro RequestTooLarge quando o tamanho começa a exceder o limite de 10 MB com o código de falha protocol.http.TooBigBody.

Resolução

Tamanho fixo

Opção 1 [recomendada]: corrija o aplicativo cliente para não enviar um tamanho de payload maior que o limite permitido.

  1. Analise o motivo de o cliente específico enviar solicitações / tamanho do payload acima do limite permitido, conforme definido em Limites.

  2. Se não for desejável, modifique o aplicativo cliente para que ele envie solicitações / tamanhos de payload menores que o limite permitido.

    No exemplo acima, você pode corrigir o problema transmitindo um arquivo menor, digamos, um payload test5mbfile (com tamanho de 5 MB), conforme mostrado abaixo: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. Se for desejável e você quiser enviar uma solicitação/carga útil maior que o limite permitido, acesse as próximas opções.

Padrão de URL assinado

Opção 2 [recomendada]: use o padrão de URLs assinados em um JavaCallout da Apigee

Para payloads maiores que 10 MB, a Apigee recomenda o uso de um padrão de URLs assinados em um Apigee JavaCallout, ilustrado pelo exemplo Edge Callout: Signed URL Generator no GitHub.

Streaming

Opção 3 : usar streaming

Se o proxy de API precisar processar solicitações e/ou respostas muito grandes, ative o streaming na Apigee.

CwC

Opção 4 : usar a propriedade CwC para aumentar o limite do buffer

Essa opção só deve ser usada quando não for possível usar nenhuma das opções recomendadas, já que pode haver problemas de desempenho se o tamanho padrão for aumentado.

O Apigee fornece uma propriedade CwC que permite aumentar o limite de tamanho do payload de solicitação e resposta. Para mais detalhes, consulte Definir o limite de tamanho da mensagem no roteador ou no processador de mensagens

Limites

A Apigee espera que o aplicativo cliente e o servidor de back-end não enviem tamanhos de payload maiores que o limite permitido, conforme documentado para Request/response size em Limites do Apigee Edge.

  1. Se você for um usuário da nuvem pública, o limite máximo para o tamanho do payload de solicitação e resposta será o documentado para Request/response size em Limites do Apigee Edge.
  2. Se você for um usuário da nuvem privada , talvez tenha modificado o limite padrão para o tamanho do payload de solicitação e resposta, embora não seja uma prática recomendada. Para determinar o limite máximo de tamanho do payload da solicitação, siga as instruções em Como verificar o limite atual.

Como verificar o limite atual?

Nesta seção, explicamos como verificar se a propriedade HTTPRequest.body.buffer.limit foi atualizada com um novo valor nos processadores de mensagens.

  1. Na máquina do processador de mensagens, procure a propriedade HTTPRequest.body.buffer.limit no diretório /opt/apigee/edge-message- processor/conf e verifique qual valor foi definido usando o seguinte comando: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. Confira um exemplo de resultado do comando acima: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. No exemplo de saída acima, observe que a propriedade HTTPRequest.body.buffer.limit foi definida com o valor 10m em http.properties.

    Isso indica que o limite para o tamanho do payload da solicitação configurado no Apigee para nuvem privada é de 10 MB.

Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisa de informações de diagnóstico.

É necessário coletar informações de diagnóstico

Reúna as seguintes informações de diagnóstico e entre em contato com o suporte do Apigee Edge:

Se você for um usuário da nuvem pública, forneça as seguintes informações:

  • Nome da organização
  • Nome do ambiente
  • Nome do proxy de API
  • Comando curl completo usado para reproduzir o erro 413
  • Arquivo de rastreamento para as solicitações de API

Se você for um usuário da nuvem privada, forneça as seguintes informações:

  • Mensagem de erro completa observada para as solicitações com falha
  • Nome da organização
  • Nome do ambiente
  • Pacote de proxy de API
  • Arquivo de rastreamento para as solicitações de API com falha
  • Comando curl completo usado para reproduzir o erro 413

  • Registros de acesso do NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Em que:ORG, ENV e PORT# são substituídos por valores reais.

  • Registros do sistema do processador de mensagens /opt/apigee/var/log/edge-message-processor/logs/system.log