413 Entidade de solicitação muito grande - TooBigBody

Esta é a documentação do Apigee Edge.
Acesse 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 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ê poderá encontrar 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 A solicitação HTTP é maior que o limite permitido no Apigee Edge .

Aqui estã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 a Apigee Edge é além do limite permitido no Apigee Edge. Usuários de nuvem pública e privada de borda
O tamanho do payload da solicitação excede o limite permitido após descompressão O tamanho do payload enviado em formato compactado pelo aplicativo cliente como parte do HTTP solicitação para o Apigee Edge é maior do que o limite permitido quando descompactada pelo Apigee Edge. Usuários de nuvem pública e privada 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 a API Monitoring:

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

  2. Mude para a organização na qual você quer investigar o problema

  3. Navegue até o menu 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. Compare Código de falha com Time.

  7. Selecione uma célula que tenha o Código de falha protocol.http.TooBigBody e Código de status 413como mostrado abaixo:

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

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

    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 da falha:protocol.http.TooBigBody.
    • Tamanho da solicitação(bytes): 15360440 (aproximadamente 15 MB)

    Se a Origem da falha tiver o valor proxy , o Código da falha tem o valor protocol.http.TooBigBody e Request Length. tiver mais de 10 MB, isso indica que a solicitação HTTP do cliente tem um o tamanho do 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 da falha:protocol.http.TooBigBody.
    • Tamanho da solicitação(bytes): 15264 (~15 KB)

    Se a Origem da falha tiver o valor proxy , o Código da falha tem o valor protocol.http.TooBigBody e o Comprimento da solicitação é menos de 10 MB, isso indica que a solicitação HTTP do cliente tem um tamanho de payload de solicitação menor que o limite permitido em seu formato compactado, mas o 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ê puder reproduzir o problema, faça a chamada de API e reproduza-o 413 Request Entity Too Large erro

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

  3. Selecione uma das solicitações com falha e examine o trace.
  4. Navegue até 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
    • Comprimento do conteúdo: 15360204

    Compactado

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

    Observe as seguintes informações:

    • Codificação de conteúdo: gzip
    • Comprimento do conteúdo: 14969
    • Tipo de conteúdo: application/x-gzip
  5. Navegar pelas diferentes fases do trace e localizar onde a falha ocorreu.

  6. Você encontrará o erro normalmente em um fluxo depois que o Request Received from from cliente, conforme mostrado abaixo:

  7. Anote o valor do erro do trace. O trace 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 na rastros. 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 (Analytics Data Recorded) no trace e clique nela.

  10. Na seção Detalhes da fase, role para baixo até Leitura de variáveis.

  11. Determine o valor da variável client.received.content.length, que indica:
    • O tamanho real da carga útil da solicitação quando ela é enviada em formato descompactado e
    • O tamanho do payload da solicitação na descompactação pela Apigee, quando o payload é enviados em formato compactado. Ele será sempre o mesmo que o valor limite de 10 MB nesse caso.
    .

    Não compactado

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

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

    Compactado

    Cenário 2: solicitar payload no formato compactado

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

  12. A tabela a seguir explica por que o erro 413 é retornado pela Apigee em os 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 > máximo permitido de 10 MB.
    Solicitar payload em formato compactado Aprox. 10 MB

    Limite de tamanho excedido na descompactação

NGINX

Para diagnosticar o erro usando 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 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 já aconteceu) ou se ainda há solicitações com falha 413:
  4. Se você encontrar erros 413 com a correspondência X-Apigee-fault-code o valor de protocol.http.TooBigBody e, em seguida, determine o valor do X-Apigee-fault-source.

    Não compactado

    Cenário 1 : tamanho do payload da solicitação no formato descompactado

    O exemplo de entrada 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

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

    Compactado

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

    O exemplo de entrada do registro de acesso do NGINX acima 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

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

    Nesse cenário, a Apigee Edge retorna 413, mesmo que o O Comprimento da solicitação é menor que o limite permitido porque a solicitação pode foram enviadas em formato compactado, e o tamanho do payload excede o limite após descompactação pela Apigee Edge.

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

Diagnóstico

  1. Determine o Código da falha, a Origem da falha e o Tamanho do payload da solicitação do observado ao usar os registros de acesso do API Monitoring, da ferramenta Trace ou do NGINX, conforme explicado em Etapas comuns de diagnóstico com o cenário 1 (descompactado).
  2. Se a Origem da falha tiver o valor policy ou proxy, esse 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 Request Payload Tamanho, conforme determinado na etapa 1.
  4. Também é possível validar se o tamanho do payload da solicitação é realmente maior que Limite permitido de 10 MB por verificar 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, execute a etapas a seguir:
      1. Verifique o tamanho do payload transmitido na solicitação.
      2. Se você achar que o tamanho da carga útil é maior 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 dele 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 no formato compactado e o cabeçalho da solicitação Content-Encoding está definido como gzip, A Apigee descompacta a solicitação payload. Durante o processo de descompactação, se a Apigee achar que o tamanho do payload é maior que 10 MB, o limite permitido, ele 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. Determinar o código da falha, a origem da falha e o tamanho do payload da solicitação. do erro observado ao usar os registros de monitoramento de APIs, da ferramenta Trace ou de acesso do NGINX, conforme explicado em Etapas de diagnóstico comuns 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 do que o limite permitido no Apigee Edge.
  3. Verifique o Request Payload Tamanho, conforme determinado na etapa 1.
    • Se o tamanho do payload > O limite permitido de 10 MB é esse que é a causa do erro.
    • Se o tamanho do payload < o limite permitido de 10 MB, é possível que a solicitação payload é transmitido no formato compactado. Nesse caso, verifique o tamanho descompactado do payload de solicitação compactado.
  4. Você pode validar se a solicitação do cliente foi enviada em formato compactado e o o tamanho descompactado era maior que o limite permitido usando um dos itens a seguir métodos:

    Trace

    Para validar usando a ferramenta Trace:

    1. Se você capturou um trace da 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 bloco Content-Encoding: Cabeçalho gzip
    2. Se o valor da variável client.received.content.length for maior que o 10 MB, o limite permitido e o cabeçalho da solicitação Content-Encoding: gzip, então 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, execute a etapas a seguir:
      1. Verifique o tamanho do payload transmitido na solicitação junto com os 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 descompactado test15mbfile é de aproximadamente 15 MB e o cabeçalho Content-Encoding é gzip.

        Se você estiver usando outro cliente, acesse os registros dele para descobrir o tamanho do payload que está sendo enviado e se o cabeçalho Content-Encoding estiver 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 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 no passado) ou se há alguma solicitação ainda falhando 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 o total bytes lidos é > 10 MB, ele para e mostra a seguinte linha: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Significa que o Tamanho do payload da solicitação é superior a 10 MB e a Apigee gera o erro RequestTooLarge quando o tamanho começa a exceder o limite de 10 MB. Com código de falha como protocol.http.TooBigBody

Resolução

Corrigir tamanho

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

  1. Analisar o motivo pelo qual o cliente específico enviou um tamanho de solicitação / payload maior que o permitido limite, conforme definido em Limites.

  2. Se não for desejável, modifique seu aplicativo cliente para que ele envie solicitação / payload um tamanho menor que o limite permitido.

    No exemplo discutido acima, você pode corrigir o problema passando um arquivo de tamanho menor, Digamos que o payload de test5mbfile (com tamanho de 5 MB) seja carregado, 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 maior do que o limite permitido, acesse as próximas opções.

Padrão de URL assinado

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

Para payloads maiores que 10 MB, a Apigee recomenda usar um padrão de URLs assinados em uma Apigee JavaCall, ilustrada pela Exemplo de Edge Frase de destaque: Gerador de URL assinado (em inglês) no GitHub.

Streaming

Opção 3 : usar streaming

Se o proxy de API precisar lidar com solicitações e/ou respostas muito grandes, ative 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 nenhuma das opções recomendadas. problemas de desempenho se o tamanho padrão for aumentado.

A Apigee oferece 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 de mensagens no roteador ou 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 de solicitações e respostas tamanho do payload está conforme documentado para Request/response size em Limites do Apigee Edge.
  2. Se você for um usuário da nuvem privada , talvez tenha modificado o padrão limite para o tamanho da carga da solicitação e da resposta (mesmo que não seja uma prática recomendada). É possível determinar o limite máximo de tamanho de payload de solicitação seguindo 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, pesquise 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. O resultado de amostra 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 definido com o valor 10m em http.properties

    Isso indica que o limite para o tamanho do payload de solicitação configurado na Apigee para Private Google Cloud é de 10 MB.

Se você ainda precisar de ajuda do suporte da Apigee, acesse É necessário coletar informações de diagnóstico.

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

Colete as informações de diagnóstico a seguir 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 da 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 estas 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 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