Suponho que você está enviando um cabeçalho HTTP Strict-Transport-Security
(HSTS) do bloco do servidor HTTPS.
O objetivo do cabeçalho da HSTS é vincular-se ao nome de domínio do qual foi recebido. É então conhecido como um host HSTS pelo User-Agent (UA) e mantido em seu cache por max-age
segundos.
Durante esse tempo, mais solicitações HTTP para o domínio, ou um subdomínio válido, se informado pela diretiva includeSubDomains
, passarão por um processamento especial descrito por RFC 6797 seção 8.3 :
The UA MUST replace the URI scheme with "https" [RFC2818], and if the URI contains an explicit port component of "80", then the UA MUST convert the port component to be "443", or if the URI contains an explicit port component that is not equal to "80", the port component value MUST be preserved; otherwise, if the URI does not contain an explicit port component, the UA MUST NOT add one. NOTE: These steps ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS Host. NOTE: In the case where an explicit port is provided (and to a lesser extent with subdomains), it is reasonably likely that there is actually an HTTP (i.e., non-secure) server running on the specified port and that an HTTPS request will thus fail (see item 6 in Appendix A ("Design Decision Notes")).
Isso significa que, se você estiver tentando enviar uma solicitação HTTP para um host HSTS conhecido com um nome de domínio correspondente ( seção 8.2 para os detalhes) e enquanto a entrada do host HSTS no cache do UA não tiver expirado, o tráfego HTTP será alternado de forma transparente para o HTTPS:
- na porta 443 se a porta HTTP fosse 80 (explícita ou implicitamente) no URI de destino
- na mesma porta caso contrário