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

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

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 este 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 de nuvens públicas e privadas de borda
Solicitação HTTP para um endpoint de destino configurado com TLS Solicitação HTTP feita para um servidor de back-end com TLS ativado no endpoint de destino. Usuários de nuvens públicas e privadas de borda
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 de nuvens públicas e privadas de borda

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

Esse erro ocorre quando um cliente está tentando 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 norte 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 incluídas nos registros de acesso do roteador NGINX. Portanto, essas solicitações não serão capturadas em ferramentas como o monitoramento de APIs e a ferramenta Trace.

  1. Verifique sua solicitação de API e veja se você está fazendo uma solicitação HTTP para um alias de host configurado para aceitar solicitações somente na porta segura 443. Se sim, 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. No exemplo de solicitação acima, uma solicitação HTTP é feita para o alias de host myorg-test.apigee.net na porta segura 443. Essa é a causa do erro 400 Bad Request.

Resolução

Você precisa 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 por TLS

Esse erro ocorrerá se você tiver configurado incorretamente 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 de rastreamento:

  1. Ative o Trace na IU da Apigee para o proxy de API afetado.
  2. Fazer solicitações ao proxy da 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 vindo do servidor de back-end. Ou seja, você vai receber a resposta de erro 400 na fase Resposta recebida do servidor de destino, conforme mostrado abaixo:

  6. Determine o endpoint de destino para o qual a solicitação foi feita clicando no ícone AX (Analytics Data Recorded) no trace.

  7. Observe o target.url, que contém o protocolo, o alias de 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ê usa o protocolo como http no elemento <URL>, essa é 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 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, como mostrado 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, então:

    • 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 detecta em uma porta não segura padrão.
    • Mencione o número da porta se você estiver usando qualquer 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 o SSL, ele fará com que o processador de mensagens do Apigee Edge envie solicitações HTTP para um servidor de destino seguro ou configurado com TLS, causando esse problema.

Diagnóstico

Siga estas etapas para diagnosticar o erro usando a ferramenta de rastreamento:

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

  5. Normalmente, você vai ver a resposta de erro 400 vindo 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. Determine o endpoint de destino para o qual a solicitação foi feita clicando no ícone AX (Analytics Data Recorded) no trace.

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

    No exemplo de arquivo de rastreamento acima, o target.name é default. Isso indica que o endpoint de destino usado para essa solicitaçã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>

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

  9. Quando você tiver o nome do servidor de destino, poderá usar um dos seguintes métodos para verificar a configuração dele:

    • interface do Edge
    • API Management

interface do Edge

  1. Navegue até Apigee Edge > Admin > Environments > Target Servers.
  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 ver 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 não estiver 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
}

    No exemplo de saída acima, a porta usada para a conexão de destino é 443, mas não há nenhum 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 isso, use uma das seguintes opções:

  • interface do Edge
  • API Management

interface do Edge

  1. Navegue até o servidor de destino em IU de borda > Administrador > 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 marcando a caixa de seleção ao lado da opção SSL.
  4. Configure Truststore, Criptografias e Protocolos. (Apenas se necessário)

API Management

Use a API de gerenciamento para configurar o servidor de destino, conforme descrito no artigo Atualizar a configuração do servidor de destino.

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

Se o problema persistir mesmo após seguir as instruções acima, colete as informações de diagnóstico a seguir e entre em contato com o suporte do Apigee Edge.

  1. Se você for usuário da nuvem pública, forneça as seguintes informações:
    • Nome da organização
    • Nome do ambiente
    • Nome do proxy da API
    • Concluir o comando curl para reproduzir o erro
    • Saída da ferramenta de rastreamento (se você conseguiu capturar a solicitação com falha)
  2. Se você for usuário de uma 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 de rastreamento (se você conseguiu capturar a solicitação com falha)