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

Esta é a documentação do Apigee Edge.
Acesse 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 o seguinte código de resposta: 

HTTP/1.1 400 Bad Request

Depois, esta é a 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 nuvem pública e privada de borda
Solicitação HTTP para um endpoint de destino configurado por TLS Solicitação HTTP feita para um servidor de back-end ativado para TLS no endpoint de destino. Usuários de nuvem pública e privada 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 nuvem pública e privada de borda

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 os é configurado para usar SSL e recebe uma solicitação HTTP.

Diagnóstico

Como o problema ocorre endpoint norte-americano e as solicitações da API falham na interação do ponto de entrada entre os aplicativo cliente e o roteador, essas mensagens de erro não são registradas no roteador NGINX registros de acesso. Portanto, essas solicitações não serão capturadas em ferramentas como 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 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. No exemplo de solicitação acima, observe que uma solicitação HTTP é feita para o alias de host. myorg-test.apigee.net na porta segura 443. Essa é a causa da 400 Bad Request erro.

Resolução

Você precisa verificar se o cliente está usando HTTP em vez de HTTPs e fazer a solicitação correta como mostrados 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 solicitações HTTP incorretamente para um back-end ativado para TLS de destino no endpoint de um proxy de API.

Diagnóstico

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

  1. Ative o Trace na IU da Apigee para o proxy de API afetado.
  2. Fazer 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, a resposta de erro 400 aparece no 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. Determinar o endpoint de destino para o qual a solicitação foi feita clicando em 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 faz detecções em uma porta segura, como 443. Se você estiver usando 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 é segura porta 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 por TLS, use o protocolo como https no elemento <URL> do endpoint de destino, conforme mostrado em 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:

    • Não mencione o número da porta segura, como 443.
    • Você não precisa mencionar o número da porta se o servidor de back-end detectar uma porta não segura padrão
    • Mencione o número da porta se 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, ele faz com que o processador de mensagens do Apigee Edge envie solicitações HTTP a um servidor O servidor de destino configurado por TLS está causando esse problema.

Diagnóstico

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

  1. Ative o Trace na IU da Apigee para o proxy de API afetado.
  2. Fazer 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, a resposta de erro 400 do servidor de back-end é mostrada. Ou seja, você verá a resposta de erro 400 na fase Resposta recebida: do servidor de destino, conforme mostrado abaixo:

  6. Determinar o endpoint de destino para o qual a solicitação foi feita clicando em 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 do exemplo acima, o target.name é default. Isso indica que o endpoint de destino usado nesta 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>

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

  9. Assim que tiver o nome do servidor de destino, você poderá usar um dos métodos a seguir para verifique a configuração do servidor de destino:

    • interface do Edge
    • API Management

interface do Edge

  1. Acesse Apigee Edge > Administrador > 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 está ativado, essa é a causa do problema.

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

API Management

  1. Execute o Acessar a API do servidor de destino para acessar 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 se a seção SSLInfo não está definida ou não está ativada, essa é a causa do esse 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, podemos notar 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 servidor de destino.

Você pode fazer isso usando uma das seguintes opções:

  • interface do Edge
  • API Management

interface do Edge

  1. Navegue até o servidor de destino na interface do Edge > 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 da seguinte forma: marcando a caixa de seleção ao lado da opção SSL.
  4. Configure Truststore, Criptografias e Protocolos. (Apenas se exigido)

API Management

Use a API de gerenciamento para configurar o servidor de destino, conforme descrito nas Atualize a documentação da configuração do servidor de destino.

É 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: informações de diagnóstico e entre em contato com o suporte do Apigee Edge.

  1. Se você for um usuário de nuvem pública, forneça as seguintes informações:
    • Nome da organização
    • Nome do ambiente
    • Nome do proxy da API
    • Complete 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ê é usuário de 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 servidor de destino no seu endpoint)
    • Saída da ferramenta de rastreamento (se você conseguiu capturar a solicitação com falha)