502 Gateway inválido - 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 502 Bad Gateway 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 502 Bad Gateway

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 servidor de destino/back-end para o Apigee Edge como parte da resposta HTTP for maior que o limite permitido no Apigee Edge.

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

Causa Descrição Instruções de solução de problemas aplicáveis para
O tamanho do payload da resposta é maior que o limite permitido O tamanho do payload enviado pelo servidor de destino/back-end como parte da resposta HTTP para a Apigee é maior que o limite permitido. Usuários de nuvens públicas e privadas de borda
O tamanho do payload da resposta excede o limite permitido após a descompactação O tamanho do payload enviado em formato compactado pelo servidor de destino/back-end como parte da resposta HTTP à Apigee é maior do que o limite permitido quando descompactado pela Apigee. 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. Alterne 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, conforme mostrado abaixo:

  8. Você verá as informações sobre o código de falha protocol.http.TooBigBody, conforme mostrado abaixo:

  9. Clique em Ver registros e expanda a linha da solicitação com falha.

  10. Na janela "Registros", observe os seguintes detalhes:
    • Código de status: 502
    • Origem da falha: target
    • Código de falha: protocol.http.TooBigBody.
  11. Se a Origem da falha tiver o valor target e o Código de falha tiver o valor protocol.http.TooBigBody, isso indica que a resposta HTTP do servidor de destino/ back-end tem um tamanho de payload de resposta maior que o limite permitido no Apigee Edge.

Trace

Para diagnosticar o erro usando a ferramenta Trace:

  1. Ative a sessão de rastreamento e:
    • Aguarde a ocorrência do erro 502 Bad Gateway ou
    • Se você conseguir reproduzir o problema, faça a chamada de API e reproduza o erro 502 Bad Gateway.
  2. Selecione uma das solicitações com falha e examine o rastro.
  3. Navegue pelas diferentes fases do rastro e localize onde a falha ocorreu.

  4. Navegue para a fase Erro logo após a fase Resposta recebida do servidor de destino, conforme mostrado abaixo:

    Observe os valores do erro do trace:

    • erro: Body buffer overflow
    • error.class: com.apigee.errors.http.server.BadGateway

    Isso indica que o Apigee Edge (componente de processador de mensagens) gera o erro assim que recebe a resposta do servidor de back-end devido ao tamanho do payload que excede o limite permitido.

  5. Você verá a falha na fase Resposta enviada ao cliente, conforme mostrado abaixo:

  6. Observe os valores do erro do rastro. O rastro de amostra acima mostra:
    • erro: 502 Bad Gateway
    • Conteúdo do erro: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}

  7. Navegue até a fase Resposta recebida do servidor de destino, conforme mostrado abaixo em diferentes cenários:

    Não compactado

    Cenário 1: payload da resposta enviado em formato descompactado

    Observe os valores do erro do trace:

    • Resposta recebida do servidor de destino: 200 OK
    • Content-Length (da seção Content-Length): ~11 MB

    Compactado

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

    Observe os valores do erro do trace:

    • Resposta recebida do servidor de destino: 200 OK
    • Content-Encoding: se você vir esse cabeçalho na seção Cabeçalhos de resposta, anote o valor. Por exemplo, neste exemplo, o valor é gzip.

  8. Observe o Corpo na seção Conteúdo da resposta:

    {"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 para conferir os detalhes relacionados.

  10. Role para baixo em Phase Details até a seção Variables Read e determine os valores de target.received.content.length, que indicam:
    • O tamanho real do payload da resposta quando ele é enviado em formato descompactado e
    • O tamanho do payload da resposta 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 da resposta enviado em formato descompactado

    Observe o valor de target.received.content.length:

    Cabeçalhos de solicitação Valor
    target.received.content.length Aprox. 11 MB

    Compactado

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

    Observe o valor de target.received.content.length:

    Cabeçalhos de solicitação Valor
    target.received.content.length Aprox. 10 MB

  11. A tabela a seguir explica por que o erro 502 é retornado pela Apigee nos dois cenários com base no valor de target.received.content.length:

    Cenário Valor de target.received.content.length Motivo da falha
    Payload da resposta no formato descompactado Aprox. 11 MB Tamanho > o limite permitido de 10 MB
    Payload de resposta 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 502.

  2. Verifique os 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.

  3. Pesquise se há erros 502 durante um período específico (se o problema ocorreu anteriormente) ou se há alguma solicitação que ainda falha com 502.
  4. Se você encontrar erros 502 com o X-Apigee-fault-code correspondente ao valor de protocol.http.TooBigBody, determine o valor de X-Apigee-fault-source.

    Exemplo de erro 502 do registro de acesso do NGINX:

    A entrada de amostra 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 target

Causa: o tamanho do payload da resposta é 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 resposta do erro observado usando o monitoramento de APIs, a ferramenta de rastreamento ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico no cenário 1.
  2. Se a origem da falha tiver o valor target, isso indica que o tamanho do payload da resposta enviado pelo servidor de destino/back-end para a Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da resposta conforme determinado na etapa 1.
  4. Para confirmar se o tamanho do payload da resposta é maior do que 10 MB permitido, verifique a resposta real com as seguintes etapas:
    1. Se você não tiver acesso à solicitação real feita ao servidor de destino/back-end, acesse Resolução.
    2. Se você tiver acesso à solicitação real feita ao servidor de destino/back-end, siga estas etapas:
      1. Se você for um usuário da nuvem pública/privada, faça uma solicitação diretamente ao servidor de back-end a partir do próprio servidor de back-end ou de qualquer outra máquina em que você tenha permissão para fazer a solicitação ao servidor de back-end.
      2. Se você for um usuário da nuvem privada, também poderá fazer a solicitação ao servidor de back-end a partir de um dos processadores de mensagens.
      3. Verifique o tamanho do payload transmitido na resposta conferindo o cabeçalho Content-Length.
      4. Se o tamanho do payload for maior do que o limite permitido no Apigee Edge, essa será a causa do problema.

    Exemplo de resposta do servidor de back-end:

    curl -v https://BACKENDSERVER-HOSTNAME/testfile

    * About to connect() to 10.14.0.10 port 9000 (#0)
*   Trying 10.14.0.10...
* Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
> GET /testfile HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.14.0.10:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 11534336
< Content-Type: application/octet-stream
< Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
< Date: Wed, 30 Jun 2021 09:22:41 GMT
<
----snipped----
<Response Body>

    No exemplo acima, é possível ver que Content-Length: 11534336 (which is ~11 MB), que é a causa desse erro, porque excede o limite permitido no Apigee Edge.

Resolução

Consulte Resolução.

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

Se o payload de resposta for enviado em formato compactado e o cabeçalho de resposta Content-Encoding estiver definido como gzip, A Apigee descompactará o payload da resposta. Durante o processo de descompactação, se a Apigee considerar que o tamanho do payload é maior do que o limite permitido no Apigee Edge., ela interrompe a descompactação adicional e responde imediatamente com 502 Bad Gateway 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 resposta do erro observado usando os registros de monitoramento da API, da ferramenta de rastreamento ou do acesso NGINX, conforme explicado em Etapas comuns de diagnóstico no cenário 2.
  2. Se a Origem da falha tiver o valor target, isso indica que o tamanho do payload da resposta enviado pelo aplicativo de destino/back-end para a Apigee é maior que o limite permitido no Apigee Edge.
  3. Verifique o Tamanho do payload da resposta 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 de aproximadamente 10 MB, o payload de resposta poderá ser transmitido no formato compactado. Nesse caso, verifique o tamanho descompactado do payload de resposta compactada.
  4. É possível validar se a resposta do destino/back-end foi enviada em formato compactado e o tamanho descompactado foi maior que o limite permitido usando um dos métodos a seguir:

    Trace

    Como usar 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 de target.received.content.length.
      2. Verifique se a solicitação do cliente continha o cabeçalho Content-Encoding: gzip
    2. Se o valor de target.received.content.length estiver próximo do limite permitido de 10 MB e o cabeçalho de resposta target.received.content.length , essa será a causa desse erro.

    Solicitação real

    Como usar a solicitação real:

    1. Se você não tiver acesso à solicitação real feita ao servidor de destino/back-end, acesse Resolução.
    2. Se você tiver acesso à solicitação real feita ao servidor de destino/back-end, siga estas etapas:
      1. Verifique o tamanho do payload transmitido na resposta com o cabeçalho Content-Encoding enviado na resposta.
      2. Se você achar que o cabeçalho de resposta Content-Encoding está definido como gzip e o tamanho descompactado do payload é maior que o limite permitido no Apigee Edge, essa é a causa do erro.

        Exemplo de resposta recebida do servidor de back-end:

        curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz

        * About to connect() to 10.1.0.10 port 9000 (#0)
*   Trying 10.1.0.10...
* Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
> GET /testzippedfile.gz HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.1.0.10:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Encoding: gzip
< Content-Type: application/x-gzip
< Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
< Testheader: test
< Date: Wed, 07 Jul 2021 10:14:16 GMT
< Transfer-Encoding: chunked
<
----snipped----
<Response Body>

        No caso acima, o cabeçalho Content-Encoding: gzip é enviado e o tamanho do arquivo testzippedfile.gz na resposta é menor que o limite. No entanto, o tamanho do arquivo descompactado testzippedfile era de aproximadamente 15 MB.

    Registros do processador de mensagens

    Como usar 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 502.

    2. Verifique os registros do processador de mensagens

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

    3. Pesquise se há erros 502 durante um período específico (se o problema aconteceu anteriormente) ou se há alguma solicitação que ainda falha com 502. Você pode usar as seguintes strings de pesquisa:

      grep -ri "chunkCount"

      grep -ri "BadGateway: Body buffer overflow"
    4. Você vai encontrar linhas de system.log semelhantes à mostrada abaixo (TotalRead e chunkCount podem variar no seu caso): 
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
TotalRead 10489856 chunkCount 2571

2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
HTTPClient$Context.onInputException() :
ClientInputChannel(ClientChannel[Connected:
Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
isOpen=true).onExceptionRead exception: {}
com.apigee.errors.http.server.BadGateway: Body buffer overflow

2021-07-07 09:40:47,012  NIOThread@7 ERROR
ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
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 2571

      Isso implica que o Tamanho do payload da resposta é maior que 10 MB, e a Apigee gera o erro 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 do servidor de destino para não enviar um payload que exceda o limite da Apigee

  1. Analise por que o servidor de destino específico pode enviar o tamanho da resposta / payload além do limite permitido, conforme definido em Limites.
  2. Se não for, modifique o aplicativo do servidor de destino para que ele envie um tamanho de resposta / payload menor que o limite permitido.
  3. Se for desejável e você quiser enviar uma resposta/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 em Limites do Apigee Edge.

  1. Se você for um usuário de 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 do Apigee Edge.
  2. Se você for um usuário de nuvem privada , talvez tenha modificado o limite máximo 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 HTTPResponse.body.buffer.limit foi atualizada com um novo valor nos processadores de mensagens.

  1. Na máquina do processador de mensagens, pesquise a propriedade HTTPResponse.body.buffer.limit no diretório /opt/apigee/edge-message- processor/conf e verifique qual valor foi definido conforme mostrado abaixo:

    grep -ri "HTTPResponse.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:HTTPResponse.body.buffer.limit=10m

  3. No exemplo de saída acima, observe que a propriedade HTTPResponse.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 É necessário 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 502
  • Arquivo de rastreamento das solicitações de API
  • Saída completa da resposta do servidor de destino/back-end junto com o tamanho do payload

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 502
  • Saída completa da resposta do servidor de destino/back-end junto com o tamanho do payload

  • 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