400 Solicitação inválida - solicitação HTTP simples enviada para a porta HTTPS

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

Sintoma

O aplicativo cliente recebe uma resposta HTTP 400 Bad Request com a mensagem The plain HTTP request was sent to HTTPS port.

Mensagem de erro

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

HTTP/1.1 400 Bad Request

Seguido pela página de erro HTML abaixo: 

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

Causas possíveis

Causa Descrição Instruções de solução de problemas aplicáveis para
Solicitação HTTP para um host virtual configurado com TLS O cliente envia uma solicitação HTTP para um host virtual configurado com TLS Usuários da nuvem pública e privada do Edge
Solicitação HTTP para um endpoint de destino configurado com TLS Solicitação HTTP feita para um servidor de back-end ativado para TLS no endpoint de destino. Usuários da nuvem pública e privada do Edge
Configuração incorreta do servidor de destino O servidor de destino está configurado com a porta segura 443, mas o SSL não está ativado. Usuários da nuvem pública e privada do Edge

Causa: solicitação HTTP para um host virtual configurado com TLS

Esse erro ocorre quando um cliente tenta se conectar a uma API na Apigee e o host virtual mencionado está configurado para usar SSL e recebe uma solicitação HTTP.

Diagnóstico

Como esse problema ocorre no endpoint de saída e as solicitações de API falham na interação do ponto de entrada entre o aplicativo cliente e o roteador, essas mensagens de erro não são registradas nos registros de acesso do roteador NGINX. Portanto, essas solicitações não serão capturadas em ferramentas como o monitoramento de API e a ferramenta Trace.

  1. Verifique sua solicitação de API e confira se você está fazendo uma solicitação HTTP para um alias de host que está configurado para aceitar solicitações apenas na porta segura 443. Em caso afirmativo, essa é a causa do problema.

    Exemplo de solicitação de API incorreta :

    curl http://org-test.apigee.net:443/400-demo

    <html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>server</center>
</body>
</html>
  2. Na solicitação de exemplo acima, observe que uma solicitação HTTP é feita para o alias de host myorg-test.apigee.net na porta segura 443. Essa é a causa do 400 Bad Request erro.

Resolução

É necessário verificar se o cliente está usando HTTP em vez de HTTPS e fazer a solicitação correta, conforme mostrado abaixo:

Exemplo de solicitação de API :

curl https://org-test.apigee.net:443/400-demo

ou

curl https://org-test.apigee.net/400-demo

< HTTP/1.1 200 OK
< Date: Thu, 25 Feb 2021 13:01:43 GMT
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 403
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true

Causa: solicitação HTTP para um endpoint de destino configurado com TLS

Esse erro ocorre se você configurou incorretamente as solicitações HTTP para um servidor de back-end ativado para TLS no endpoint de destino de um proxy de API.

Diagnóstico

Siga estas etapas para diagnosticar o erro usando a ferramenta Trace:

  1. Ative o Trace na interface da Apigee para o proxy de API afetado.
  2. Faça solicitações ao proxy de API.
  3. Selecione uma das solicitações de API que falharam com o código de resposta 400.
  4. Navegue pelas várias fases e determine onde a falha ocorreu.

  5. Normalmente, você verá a resposta de erro 400 vinda do servidor de back-end. Ou seja, você verá a resposta de erro 400 na fase Resposta recebida do servidor de destino , conforme mostrado abaixo:

  6. Para determinar o endpoint de destino para o qual a solicitação foi feita, clique no ícone AX (dados de análise registrados) no trace.

  7. Observe o target.url, que contém o protocolo, o alias do host do servidor de back-end, e, às vezes, o número da porta. A porta usada para o URL de destino é 443 mas o protocolo é HTTP.
  8. Revise a definição do endpoint de destino para entender a configuração.

  9. Verifique se o host do servidor de back-end é seguro e detecta em uma porta segura, como 443. Se você estiver usando o protocolo como http no elemento <URL>, então essa será a causa do problema.

    Exemplo de configuração do endpoint de destino :

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org:443/get</URL>
    </HTTPTargetConnection>
</TargetEndpoint>

    O exemplo acima mostra que você está usando o protocolo HTTP, mas a porta usada é a porta segura port 443. Isso faz com que o servidor de back-end responda com 400 Bad Request e a mensagem de erro The plain HTTP request was sent to HTTPS port.

Resolução

  1. Se o servidor de back-end for seguro/ativado para TLS, use o protocolo como https no elemento <URL> do endpoint de destino, conforme mostrado em no exemplo a seguir:

    Exemplo de configuração do endpoint de destino :

    <HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>

  2. Se o servidor de back-end não for seguro, faça o seguinte:

    • Não mencione o número da porta segura, como 443.
    • Não é necessário mencionar o número da porta se o servidor de back-end detectar em uma porta não segura padrão.
    • Mencione o número da porta se você estiver usando outra porta não segura, por exemplo: 9080

    Exemplo de configuração do endpoint de destino :

    <HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org/get</URL>
</HTTPTargetConnection>

or

<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org:9080/get</URL>
</HTTPTargetConnection>

Causa: configuração incorreta do servidor de destino

Se o servidor de destino estiver configurado com uma porta segura, como 443, sem ativar SSL, isso fará com que o processador de mensagens do Apigee Edge envie solicitações HTTP para um servidor de destino seguro ou configurado com TLS, levando a esse problema.

Diagnóstico

Siga estas etapas para diagnosticar o erro usando a ferramenta Trace:

  1. Ative o Trace na interface da Apigee para o proxy de API afetado.
  2. Faça solicitações ao proxy de API.
  3. Selecione uma das solicitações de API que falharam com o código de resposta 400.
  4. Navegue pelas várias fases e determine onde a falha ocorreu.

  5. Normalmente, você verá a resposta de erro 400 vinda do servidor de back-end. Ou seja, você verá a resposta de erro 400 na fase Resposta recebida do servidor de destino , conforme mostrado abaixo:

  6. Para determinar o endpoint de destino para o qual a solicitação foi feita, clique no ícone AX (dados de análise registrados) no trace.

  7. Observe o target.name, que representa o nome do endpoint de destino.

    No arquivo de trace de exemplo acima, o target.name é default. Isso indica que o endpoint de destino usado para essa solicitação é o padrão.

  8. Revise a definição do endpoint de destino para entender a configuração.

    Exemplo de configuração do endpoint de destino :

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <LoadBalancer>
        <Server name="faulty-target"/>
        </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

    A configuração do endpoint de destino de exemplo acima mostra que você está usando um servidor de destino chamado faulty-target.

  9. Depois de ter o nome do servidor de destino, você pode usar um dos métodos a seguir para verificar a configuração do servidor de destino:

    • Interface do Edge
    • API Management

Interface do Edge

  1. Acesse Apigee Edge > Admin > Ambientes > Servidores de destino.
  2. Escolha o servidor de destino específico identificado no proxy de API e clique em Editar.
  3. Verifique a porta especificada para o servidor de destino e as informações de SSL.

  4. Se o servidor de destino estiver configurado com uma porta segura (por exemplo, 443), mas o SSL não estiver ativado, essa será a causa do problema.

    Como você pode ver na captura de tela acima, a porta usada é 443, mas o SSL não está ativado para essa porta na configuração do servidor de destino. Isso faz com que o processador de mensagens do Apigee Edge envie solicitações HTTP para a porta segura 443. Portanto, você recebe o erro 400 Bad Request com a mensagem The plain HTTP request was sent to HTTPS port.

API Management

  1. Execute a API Get target server para receber os detalhes sobre a configuração específica do servidor de destino conforme mostrado abaixo:

    Usuário da nuvem pública :

    curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"

    Usuário da nuvem privada :

    curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"
  2. Verifique a porta especificada para o servidor de destino e as informações de SSL.

  3. Se o servidor de destino estiver configurado com uma porta segura (por exemplo, 443), mas a seção SSLInfo não estiver definida ou ativada, essa será a causa do problema.

    Exemplo de configuração do servidor de destino :

    {
  "host" : "somehost.org",
  "isEnabled" : true,
  "name" : "faulty-target",
  "port" : 443
}

    Na saída de exemplo acima, podemos ver que a porta usada para a conexão de destino é 443, mas não há um bloco de configuração SSLInfo.

    Isso faz com que o processador de mensagens do Apigee Edge envie solicitações HTTP para a porta segura 443. Portanto, você recebe o erro 400 Bad Request com a mensagem The plain HTTP request was sent to HTTPS port.

Resolução

Se o servidor de destino for seguro ou configurado com TLS, será necessário ativar o SSL para o servidor de destino específico.

Para fazer isso, use uma das seguintes opções:

  • Interface do Edge
  • API Management

Interface do Edge

  1. Navegue até o servidor de destino em Interface do Edge > Admin > Ambientes > Servidores de destino.
  2. Escolha o servidor de destino específico e clique em Editar.
  3. Se o servidor de destino for seguro e usar uma porta como 443, ative o SSL selecionando a caixa de seleção ao lado da opção SSL.
  4. Configure Truststore, Ciphers e Protocols. (somente se necessário)

API Management

Use a API Management para configurar o servidor de destino, conforme descrito na Atualizar a configuração do servidor de destino documentação.

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

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o suporte do Apigee Edge.

  1. 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 para reproduzir o erro
    • Saída da ferramenta Trace (se você conseguiu capturar a solicitação com falha)
  2. Se você for um usuário da nuvem privada, forneça as seguintes informações:
    • Mensagem de erro completa observada
    • Nome do ambiente
    • Pacote de proxy de API
    • Definição do servidor de destino (se você estiver usando o servidor de destino no endpoint)
    • Saída da ferramenta Trace (se você conseguiu capturar a solicitação com falha)