413 Entidade de solicitação muito grande - TooBigBody

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Sintoma

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

Mensagem de erro

O aplicativo cliente recebe este código de resposta: 

HTTP/1.1 413 Request Entity Too Large

Além disso, talvez você veja a seguinte mensagem de erro: 

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

Causas possíveis

Esse erro vai ocorrer 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 .

Estas são as possíveis causas desse erro :

Causa Descrição Instruções de solução de problemas aplicáveis para
O tamanho do payload da solicitação é maior 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 de nuvens públicas e privadas de borda
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 do que o limite permitido quando descompactado pelo Apigee Edge. Usuários de nuvens públicas e privadas de borda

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 monitoramento de APIs:

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

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

  3. Navegue até a página Analisar > Monitoramento de API > Investigar.
  4. Selecione o período específico em que você observou os erros.
  5. Selecione o filtro Proxy para restringir o código da falha.
  6. Trace o Código de falha em relação a Time.

  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 conforme mostrado abaixo:

  9. Clique em Ver registros e expanda a linha da solicitação com falha. Em seguida, na janela Registros, anote os detalhes mostrados a seguir :

    Não compactado

    Cenário 1: payload da solicitação enviado em formulário descompactado

    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 de falha tiver o valor protocol.http.TooBigBody e o Comprimento da solicitação for maior que 10 MB, isso indica que a solicitação HTTP do cliente tem um tamanho de payload da solicitação maior que o limite permitido na Apigee.

    Compactado

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

    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 de falha terá o valor protocol.http.TooBigBody e o Comprimento da solicitação for menor que 10 MB, isso indica que a solicitação HTTP do cliente tem um tamanho de payload da solicitação 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:
    • Aguarde a ocorrência do erro 413 Request Entity Too Large ou
    • Se você conseguir 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 rastro.
  4. Navegue para a fase Solicitação recebida do cliente.

    Não compactado

    Cenário 1: payload da solicitação enviado em formulário descompactado

    Observe as seguintes informações:

    • Content-Encoding:ausente
    • Content-Length: 15360204

    Compactado

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

    Observe as seguintes informações:

    • Content-Encoding:gzip
    • Content-Length: 14969
    • Tipo de conteúdo: application/x-gzip
  5. Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.

  6. Você encontrará o erro normalmente em um fluxo após a fase Solicitação recebida do cliente, conforme mostrado abaixo:

  7. Observe o valor do erro do trace. O rastro de amostra acima mostra:
    • erro: Body buffer overflow
    • error.class::com.apigee.errors.http.user.RequestTooLarge

  8. Navegue até Resposta enviada ao cliente e anote os valores do erro do trace. O rastro 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 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 descompactado e
    • O tamanho do payload da solicitação após a descompactação pela Apigee, quando o payload é enviado em formato compactado. Esse valor será sempre igual ao valor do limite permitido (10 MB) nesse cenário.

    Não compactado

    Cenário 1: payload de solicitação em formato descompactado

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

    Compactado

    Cenário 2: payload da 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 descompactado Aprox. 15 MB Tamanho > limite permitido de 10 MB.
    Solicitar payload em formato compactado Aprox. 10 MB

    Limite de tamanho excedido após a descompactação

NGINX

Para diagnosticar o erro usando os registros de acesso do NGINX:

  1. Se você for um usuário da nuvem privada, poderá usar os registros de acesso do NGINX para determinar as principais informações sobre os 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 se há erros 413 durante um período específico (se o problema aconteceu anteriormente) ou se há alguma solicitação que ainda falha com 413.
  4. Se você encontrar erros 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 descompactado

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

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

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

    Compactado

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

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

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

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

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

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

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 os registros de acesso do Monitoramento de APIs, da ferramenta de rastreamento ou do NGINX, conforme explicado em Etapas comuns de diagnóstico com o cenário no 1 (não 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 à Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da solicitação conforme determinado na etapa 1.
  4. Também é possível confirmar se o tamanho do payload é maior do que 10 MB no limite permitido. Para isso, verifique 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 o tamanho do payload for maior do que o limite permitido no Apigee Edge, essa será 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 aproximadamente 15 MB. Se você estiver usando outro cliente, acesse os registros do cliente para descobrir o tamanho do payload que está sendo 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 descompactará o payload da solicitação. Durante o processo de descompactação, se a Apigee considerar 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 com 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 os registros de monitoramento de API, da ferramenta de rastreamento ou 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 à 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 ultrapassar o limite permitido de 10 MB, essa será 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 no formato compactado. Nesse caso, verifique o tamanho descompactado do payload da solicitação.
  4. É possível validar se a solicitação do cliente foi enviada em formato compactado e se o tamanho descompactado era maior que o limite permitido usando um dos métodos a seguir:

    Trace

    Para validar usando a ferramenta Trace:

    1. Se você capturou um rastro 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 os 10 MB, o limite permitido e o cabeçalho da solicitação client.received.content.length , essa será a causa desse erro.

    Solicitação real

    Para validar usando a solicitação real, faça o seguinte:

    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, além do cabeçalho Content-Encoding enviado nela.

      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 descompactado test15mbfile é de aproximadamente 15 MB, e o cabeçalho Content-Encoding é gzip.

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

    Registros do processador de mensagens

    Para validar usando os registros do processador de mensagens:

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

    2. Verifique os registros do processador de mensagens:

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

    3. Pesquise se há erros 413 durante um período específico (se o problema aconteceu anteriormente) ou se ainda há alguma solicitação com falha com 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 determinar que o total de bytes de leitura é maior que 10 MB, ele será interrompido e exibirá a seguinte linha: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Isso implica 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 como protocol.http.TooBigBody.

Resolução

Corrigir tamanho

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

  1. Analise por que o cliente específico pode enviar o tamanho da solicitação / payload acima do limite permitido, conforme definido em Limites.

  2. Se não for, modifique o aplicativo cliente para que ele envie a solicitação / payload menor que o limite permitido.

    No exemplo discutido acima, é possível corrigir o problema transmitindo um arquivo menor, digamos, o 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/payload além do limite permitido, vá para as próximas opções.

Padrão do URL assinado

Opção 2 [recomendada]: usar o padrão de URLs assinados em uma Apigee Java callout

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

Streaming

Opção 3 : usar streaming

Se o proxy de API precisar lidar com 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

Use essa opção apenas quando não for possível usar as opções recomendadas, porque poderá haver problemas de desempenho se o tamanho padrão for aumentado.

A 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 nos Limites do Apigee Edge.

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

Como verificar o limite atual?

Esta seção explica 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, pesquise a propriedade HTTPRequest.body.buffer.limit no diretório /opt/apigee/edge-message- processor/conf e verifique qual valor foi definido usando o comando a seguir: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. O resultado do exemplo do comando acima é o seguinte: 
    /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 na Apigee para nuvem privada é de 10 MB.

Se você ainda precisar de ajuda do suporte da Apigee, acesse Precisamos coletar 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 das solicitações de API

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

  • Concluir a mensagem de erro observada para as solicitações com falha
  • Nome da organização
  • Nome do ambiente
  • Pacote de proxy de API
  • Arquivo de rastreamento das 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

    Onde: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