O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

500 Erro interno do servidor - Transmissão ativada

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 de resposta HTTP 500 com a mensagem Erro interno do servidor para chamadas de API.

Mensagens de erro

Os aplicativos cliente podem receber uma resposta de erro conforme mostrado abaixo:

HTTP/1.1 500 Internal Server Error

Isso pode ser seguido por uma mensagem de erro como esta:

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Causas possíveis

O erro interno do servidor 500 pode ocorrer devido a várias causas diferentes. Este manual se concentra no erro interno do servidor 500 causado pelo acesso ao payload de solicitação/resposta quando o streaming está ativado.

Causa	Descrição	Quem pode realizar as etapas de solução de problemas
Acessar o payload com streaming ativado	Ocorreu um erro porque o payload de solicitação/resposta foi acessado quando o streaming estava ativado.	Usuários da nuvem pública e privada do Edge

Causa: acessar o payload com o streaming ativado

Diagnóstico

Procedimento 1: usar o Trace

Ative a sessão de rastreamento, e faça a chamada de API para reproduzir o problema: erro interno do servidor 500.
Selecione uma das solicitações com falha e examine o rastreamento.
Navegue por várias fases do rastreamento e localize onde a falha ocorreu.
Esse erro pode ter ocorrido enquanto uma política estava analisando o payload de solicitação/resposta.
Confira um exemplo de captura de tela de rastreamento mostrando a política JSONThreatProtection com falha e o erro "Esperando } na linha 1":

Anote as seguintes informações da saída de rastreamento, conforme mostrado na captura de tela acima:

Política com falha : JSONThreatProtection

Fluxo:solicitação de proxy

Examine a definição da política com falha e verifique o payload que está sendo analisado.

No cenário de exemplo, examine a política JSONThreatProtection chamada JSON-Threat-Protection que falhou e verifique o <Source> elemento.

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

Observe que o elemento <Source> aponta para request.. Isso significa que o erro ocorreu ao analisar o payload da solicitação.

Determine o tipo de payload que está sendo analisado verificando a solicitação de API.

É possível verificar o conteúdo do payload da solicitação e o cabeçalho Content-Type na solicitação de API. No comando cURL de exemplo a seguir, um payload JSON é usado.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Você também pode verificar a política com falha e determinar o tipo de payload que está sendo analisado. No cenário de exemplo acima, a política JSON-Threat-Protection está falhando. Isso indica que o payload precisa estar no formato JSON.

Valide se o payload está no formato correto. Se o payload não for válido, você poderá receber esse erro.

Observação: Se o payload for grande, use qualquer formatador on-line para validar o formato dele.
Se o payload for válido, mas você ainda estiver recebendo erros conforme listado na seção "Mensagens de erro", a causa desses erros é que o payload está sendo acessado quando o streaming está ativado.

Dependendo do payload que está sendo analisado pela política (conforme determinado na etapa 6), examine o conteúdo do payload na ferramenta Trace na fase apropriada.

No cenário de exemplo, o payload da solicitação está sendo analisado. Portanto, examine a "Solicitação recebida do cliente" fase no rastreamento e verifique o conteúdo da solicitação.

Se o conteúdo da solicitação estiver vazio, conforme mostrado na captura de tela acima, mesmo que você tenha enviado um payload válido, isso indica que a causa provável desse problema é que o streaming de solicitação está ativado.

Isso ocorre porque, quando o streaming está ativado, o payload da solicitação não aparece no rastreamento.

Da mesma forma, se o payload de resposta estiver sendo analisado quando o erro ocorrer, verifique o conteúdo da resposta na fase "Resposta recebida do servidor de destino".
Em seguida, examine as definições de proxy e de destino, dependendo de onde a política com falha é usada no fluxo de proxy da API. Verifique se o streaming foi ativado.

No cenário de exemplo, a política com falha foi executada no fluxo de solicitação de proxy (conforme determinado na etapa 5 acima). Portanto, examine o endpoint de proxy:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
Como mostrado no exemplo acima, o streaming de solicitação foi ativado, conforme indicado pela propriedade "request.streaming.enabled" definida como "true".

Portanto, a causa do erro é o uso da política JSONThreatProtection no proxy de API que acessa o payload da solicitação quando o streaming está ativado. Isso causa erros porque ele aciona o buffer no proxy de API e anula a finalidade de usar o streaming no Apigee Edge.

Esse erro pode não aparecer com payloads menores, mas quando você usa payloads maiores, você pode ver esses erros.
É possível verificar se o erro 500 é causado pela política verificando o valor de "X-Apigee-fault-source" na fase "AX" (dados de análise gravados) no rastreamento usando as etapas abaixo:
1. Clique na fase "AX" (dados de análise gravados) conforme mostrado na captura de tela abaixo:
2. Role os detalhes da fase até a seção "Cabeçalhos de erro" e determine os valores de "X-Apigee-fault-code", "X-Apigee-fault-source" e "X-Apigee-fault-policy" , conforme mostrado abaixo:
3. Se o valor de "X-Apigee-fault-source" for "policy" conforme mostrado na imagem acima, isso indica que o erro é causado pela política que acessa o payload quando o streaming está ativado.

Resolução

O acesso ao payload com o streaming ativado é um antipadrão, conforme explicado em Antipadrão: acessar o payload de solicitação/resposta quando o streaming estiver ativado.

Se você quiser processar o payload, desative o streaming no endpoint de proxy/destino removendo as propriedades "request.streaming.enabled" and "response.streaming.enabled"conforme mostrado no exemplo de ProxyEndpoint abaixo:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
OU
Se você quiser usar o streaming para seus proxies de API, não use nenhuma política no proxy de API que acesse o payload de solicitação/resposta.

Observação:

Neste manual, a política JSONThreatProtection foi usada para processar o payload da solicitação com o streaming ativado no cenário de exemplo. Isso levou ao erro interno do servidor 500 com erros diferentes.
Esses erros também podem ser observados com políticas como JSONToXML e XMLToJSON, que processam payloads de solicitação ou resposta quando o streaming está ativado.
Recomendamos não usar essas políticas em proxies que exigem acesso a payloads quando o streaming está ativado.
Fazer isso é um antipadrão, conforme documentado em Antipadrão: acessar o payload de solicitação/resposta quando o streaming estiver ativado.

Diagnosticar problemas usando a API Monitoring

Se você for um usuário da nuvem privada, pule este procedimento.

A API Monitoring permite isolar áreas problemáticas rapidamente para diagnosticar problemas de erro, desempenho e latência e a origem delas, como aplicativos de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Siga um cenário de exemplo que demonstra como solucionar problemas 5xx com suas APIs usando a API Monitoring. Por exemplo, você pode configurar um alerta para ser notificado quando o número de erros 500 exceder um limite específico.

Se você quiser receber uma notificação quando uma resposta de erro 500 for gerada pela política, configure o alerta para código de status 500 com a origem da falha como proxy.

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

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações de diagnóstico. Entre em contato e compartilhe-as com o suporte da Apigee.

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 com o payload da solicitação (se houver) para reproduzir o erro 500
Arquivo de rastreamento contendo as solicitações com erro interno do servidor 500
Se os erros 500 não estiverem ocorrendo no momento, forneça o período com as informações de fuso horário em que os erros 500 ocorreram no passado.

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
Organização, nome do ambiente e nome do proxy de API para os quais você está observando erros 500
Pacote de proxy de API
Payload usado na solicitação (se houver)
Arquivo de rastreamento contendo as solicitações com erro interno do servidor 500
Registros de acesso do NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)
O período com as informações de fuso horário em que os erros 500 ocorreram.