Existem dois aplicativos A e B.
A é usado para autenticar usuários e passa um token para B, B adiciona um cookie.
Algo estranho acontece sempre que o cookie expira ou após um longo período de tempo ou uma reinicialização forçada do navegador.
SEM VIOLINO:
O usuário acessa o aplicativo A, insere as credenciais e é encaminhado para o aplicativo B. Imediatamente, por três segundos, o navegador exibe uma tela preta de erro "xxx demorou muito para responder", então a página padrão é renderizada "no local" e substitui o tela de erro logo depois. Isso ocorre quando o cookie expirou ou após um longo período de tempo.
COM VIOLINO: (VER SESSÕES 61, 71 e 83)
Quando executo o mesmo cenário no violinista, onde esperaria que a tela preta "xxx demorou muito para responder", recebo a tela de erro de certificado anexada com o ícone de cadeado aberto. Eu rejeito isso três vezes. Enquanto estou descartando os erros do túnel SSL, a página do usuário padrão está sendo renderizada.
A correlação ocorre quase ao mesmo tempo em que as caixas de diálogo de bloqueio no violino são o mesmo lugar em que recebo a tela preta de erro do navegador e o aplicativo parece estar carregando em segundo plano e, em seguida, é atualizado quando totalmente carregado.
Meu pensamento é que há uma solicitação https -> http sendo "parcialmente" bloqueada de A -> B, pois B é http apenas sem certificados. Os desenvolvedores me disseram que não conseguem encontrar uma solicitação https.
Portanto, não consigo descobrir de onde vem o túnel SSL (veja a captura de tela). Meus pensamentos são.
Os desenvolvedores perderam alguma coisa e uma das chamadas é http.
Um dispositivo de rede está tentando converter a chamada para https, embora não haja reescritas de URL no servidor IIS.
O que faria com que um "xxx demorou muito para responder" preto fosse renderizado enquanto a página padrão estava carregando? Parece um cenário em que a solicitação foi alterada antes de ser totalmente lida ou algo parecido.
Após uma investigação adequada, as solicitações recebidas, embora por http, tiveram o cabeçalho Upgrade-Insecure-Requests: definido como 1. Isso, em essência, fez com que os seguintes eventos ocorressem de acordo com HSTS ou HTTP Strict Transport Security.
Solução: adicione uma ligação de certificado SSL válida ao site.
O mistério é por que o navegador renderizou a página de erro "a solicitação demorou muito" antes de renderizar o substituto para a resposta http. Bem, se a cadeia de chamadas for examinada, pode-se ver que um dos redirecionamentos, que suponho ser a atualização para https, resulta em um valor (desconhecido) para Tempo. Passar o mouse sobre o registro revela a mensagem que o acompanha - "A solicitação não pode ser mostrada aqui porque a página que a emitiu foi descarregada". Talvez o navegador interprete isso como um cliente desconectado ou parado de esperar por uma resposta. (algo interno aumenta e solicita SSL, então o navegador determina que o certificado está incorreto e abandona a solicitação) volta para uma tela de erro de imagem de estoque enquanto o segundo redirecionamento está em andamento para o http bem-sucedido.
Outra visão da tentativa de atualização e depois do downgrade.