“CUIDADO: headers provisórios são exibidos” no depurador do Google Chrome

Percebi uma estranha mensagem de aviso ao analisar os resources baixados usando o Google Chrome Inspector (F12):

Atenção headers provisórios são mostrados

insira a descrição da imagem aqui

Eu encontrei algo possivelmente relevante, Painel de Rede: adicione caucanvas sobre headers de solicitação provisórios , mas não consegui entendê-lo completamente. Perguntas relacionadas podem ser encontradas em pedidos de bloqueio do Chrome , assim como o XMLHttpRequest não pode ser carregado. Recursos descarregados mostram caucanvas: headers provisórios são mostrados .

Semelhante à primeira pergunta , meu recurso foi bloqueado, mas depois foi carregado automaticamente o mesmo recurso. Ao contrário da segunda pergunta , não quero consertar nada; Eu quero saber o que esta mensagem significa e porque eu a recebi.

O recurso pode estar sendo bloqueado por uma extensão (AdBlock no meu caso).

A mensagem está lá porque o pedido para recuperar esse recurso nunca foi feito, portanto os headers mostrados não são reais. Conforme explicado no problema mencionado, os headers reais são atualizados quando o servidor responde, mas não há resposta se a solicitação foi bloqueada.


A maneira que encontrei sobre a extensão que estava bloqueando meu recurso foi através da ferramenta net-internals no Chrome:

  • Digite chrome://net-internals na barra de endereço e pressione enter.
  • Abra a página que está mostrando problemas.
  • Volte para net-internals, clique em events (###) e use o campo de texto para encontrar o evento relacionado ao seu recurso (use partes do URL).
  • Por fim, clique no evento e veja se a informação mostrada diz alguma coisa.

Eu acredito que isso acontece quando a solicitação real não é enviada. Geralmente acontece quando você está carregando um recurso armazenado em cache.

Eu encontrei esse problema e consegui identificar uma causa específica, que não é mencionada acima nas respostas ou na pergunta.

Estou executando uma pilha js completa, front end angular e back end de nó em SSL, e a API está em um domínio diferente em execução na porta 8081, por isso estou fazendo solicitações CORS e withCredentials quando estou soltando um cookie de session da API

Então, especificamente, meu cenário era: POST request, withCredentials to port 8081 causou a mensagem “CUIDADO: headers provisórios são mostrados” no inspetor e também bloqueou a solicitação todos juntos.

Minha solução foi configurar o apache para o proxy passar a solicitação da porta SSL usual do 443 para a porta SSL do nó 8081 (o nó deve estar em uma porta mais alta, pois não pode ser executado como root no prod). Então, acho que o Chrome não gosta de solicitações de SSL para portas SSL não convencionais, mas talvez a mensagem de erro delas seja mais específica.

HTTP / 2 Recursos enviados produzirão Provisional headers are shown no inspetor pela mesma teoria que @wvega postada em sua resposta acima .

Por exemplo: Como o servidor empurrou o (s) recurso (s) para o cliente ( antes do cliente solicitá-lo ), o navegador tem os resources armazenados em cache e, portanto, o cliente nunca faz / precisa de solicitações; Então porque…

… os headers reais são atualizados quando o servidor responde, mas não há resposta se a solicitação foi bloqueada.

Eu duvido que minha resposta esteja na hora de ajudá-lo, mas outros podem achar útil. Eu experimentei um problema semelhante com um script jQuery Ajax Post que eu criei.

Descobri que eu tinha um erro de digitação no atributo href da tag A que estava usando para triggersr a postagem. Eu tinha typescript href = ” javacsript:; ” (invertendo o ‘s’ e o ‘c’) .. isso fez com que o script tentasse atualizar a página enquanto o post estava tentando triggersr. corrigido o erro e funcionou perfeitamente bem para mim.

Esta mensagem pode ocorrer quando o site é protegido usando HSTS . Então, quando alguém se conecta à versão HTTP da URL, o navegador, conforme instruído pela HSTS, não emite uma solicitação HTTP, mas redireciona internamente para o recurso HTTPS com segurança. Isso é para evitar ataques de downgrade HTTPS como o sslstrip .

Eu corri para este problema com uma chamada AJAX que nunca seria concluída. Segui o conselho da wvega e dei uma dica sobre a debugging com chrome://net-internals para eventualmente determinar outro manipulador de events de click na página, ouvindo em um nó pai, fazendo com que o navegador navegasse para a mesma URL (não era fácil perceptível).

A solução foi adicionar event.stopPropagation() em um manipulador de click no botão de envio de formulário para impedir que o clique borbulhe o DOM e cancele a solicitação AJAX em andamento (iniciada por meio de um manipulador de submit no form ).

Eu tive isso vindo muito recentemente (hoje, na verdade), onde eu tive uma chamada AJAX sair para o servidor e Chrome triggers o “Cuidado: headers provisórios são mostrados.” No script PHP do lado do servidor, existem consultas MySQL que podem ser praticamente instantâneas ou demorar alguns segundos, dependendo do cenário dado. Minha resposta do servidor não é enviada de volta ao navegador até que as consultas sejam concluídas. Eu descobri que recebo esse erro apenas quando consultas demoradas (até alguns segundos no total) estão sendo feitas e impedem que a resposta seja enviada de volta.

Meu cenário envolve a possibilidade muito rara de ter que alterar uma tabela adicionando / removendo centenas de colunas para a saída do modelo climático … portanto, o atraso de resposta é percorrer um loop de consultas ALTER TABLE.

No meu caso, era apenas um caminho de conjunto falso para um recurso (svg / img)

Esse problema ocorreu quando eu estava enviando um header de autorização HTTP inválido. Esqueci de codificar na base64.

Minha situação é de origem cruzada .
Situação: O navegador envia uma solicitação OPTIONS antes de enviar a solicitação real, como GET ou POST . O desenvolvedor backend esquece de lidar com a solicitação OPTIONS , permitindo que ela passe pelo código de serviço, tornando o tempo de processamento muito longo. Mais do que a configuração de tempo limite que escrevi na boot de axios , que é de 5000 milissegundos. Portanto, o pedido real não pôde ser enviado e, em seguida, eu encontrei os provisional headers are shown problema.
Solução: Quando se trata da solicitação OPTIONS , o backend api apenas retorna o resultado, torna a solicitação mais rápida e a solicitação real pode ser enviada antes do tempo limite.

Essa mensagem de cuidado também ocorre se a resposta for inválida e, portanto, descartada pelo navegador.

No meu caso, a solicitação foi enviada corretamente para o servidor, o código do lado do servidor produziu um erro e meu tratamento de erro personalizado retornou a mensagem de erro no campo de mensagem de status HTTP. Mas este erro não foi recebido no lado do cliente, devido a caracteres inválidos na mensagem de erro (descrita aqui http://aspnetwebstack.codeplex.com/workitem/1386 ) que resultou em headers de resposta corruptos.

Eu me deparei com isso e foi embora quando mudei de https para http. Os certificados SSL que usamos no dev não são verificados por terceiros. Eles são apenas certificados gerados localmente.

As mesmas chamadas funcionam bem no Chrome Canary e no Firefox. Esses navegadores não parecem ser tão rigorosos quanto ao certificado SSL do Chrome. As chamadas falharão no Chrome com a mensagem “CUIDADO: headers provisórios …”.

Eu acho / espero que, quando usarmos um certificado SSL legítimo em stage e prod, não veremos mais esse comportamento no Google Chrome.

Eu corri este problema quando tentei carregar main.js para exigir js pela segunda vez depois que eu fiz alterações como resultado de erro. Acabei de ligar nas Configurações das Ferramentas do Desenvolvedor “Desativar Cache (Quando o DevTools está Aberto)”. e isso fez o encanto.

Outro cenário possível que vi – a mesma solicitação está sendo enviada novamente pouco depois de alguns milissegundos (provavelmente devido a um bug no lado do cliente).
Nesse caso, você também verá que o status da primeira solicitação é “cancelado” e que a latência é de apenas vários milissegundos.

Isso estava acontecendo para mim, quando eu tinha um link de download e depois de clicar nele eu estava tentando pegar o click com jquery e enviar um pedido de ajax. O problema foi porque quando você está clicando no link de download, você está deixando a página, mesmo que não pareça. Se não houvesse transferência de arquivos, você veria a página solicitada. Por isso, defini um target = “_ blank” para evitar esse problema.

Eu recebi esse erro quando tentei imprimir uma página em um pop-up. A checkbox de diálogo de impressão foi mostrada e ainda está aguardando minha aceitação ou cancelamento da impressão no pop-up enquanto na página mestra também estava aguardando em segundo plano mostrando a mensagem CUIDADO headers provisórios são mostrados quando tentei clicar em outro link.

No meu caso, a solução foi remover o window.print (); script que estava sendo executado no da janela pop-up para evitar a checkbox de diálogo de impressão.

Uma razão comum para isso acontecer é se você estiver rastreando um evento e não impedir a ação padrão. Por exemplo, se você tiver um evento de clique, desejará include:

 e.preventDefault(); 

ou

 return false; 

Caso contrário, você verá os headers provisórios de aviso e um status “cancelado” na guia “Rede” do seu console da web.

Vi isso acontecer quando o número de conexões com o meu servidor excedeu o limite máximo de 6 conexões do Chrome por servidor.

Apenas jogando meus dois centavos. Estou escrevendo um aplicativo da Web usando solicitações CORS e um serviço Web RESTful completo. Eu encontrei chrome vai lançar esse erro quando eu tenho uma exceção não manipulada ou um erro de PHP lançado. Apenas incase alguém mais se depara com o problema. Descobri que, quando isso acontece, posso ativar o aplicativo “Postman – Rest Client” do Chrome e executar exatamente a mesma solicitação, mas, no aplicativo do Google Chrome, realmente receberei o erro do PHP sendo lançado em vez desse erro não descritivo.

Aqui está outra solução.

Se você encontrar esse problema com a chamada $ ajax (), adicione http:// antes que o seu serverhost resolva seu problema.

 var requestURL = "http://" + serverHost; $.ajax({ dataType: "json", url: requestURL, data: data, success: success }); 

Se você estiver desenvolvendo um aplicativo Asp.Net Mvc e estiver tentando retornar um JsonResult em seu controlador, inclua JsonRequestBehavior.AllowGet no método Json . Isso consertou para mim.

 public JsonResult GetTaskSubCategories(int id) { var subcategs = FindSubCategories(id); return Json(subcategs, JsonRequestBehavior.AllowGet); //<-- Notice it has two parameters } 

A mensagem “Cuidado: headers provisórios são mostrados” pode ser exibida quando o site hospedado em HTTPS chama uma chamada para o WebApi hospedado em HTTP. Você pode verificar se todas as suas Api’s são HTTPS. Navegador impede fazer uma chamada para recurso inseguro. Você pode ver uma mensagem semelhante em seu código quando usar a API FETCH para o domínio com HTTP.

Conteúdo misto: a página em ‘ https://website.com ‘ foi carregada em HTTPS, mas solicitou um recurso inseguro ‘ http://webapi.com ‘. Este pedido foi bloqueado; o conteúdo deve ser veiculado por HTTPS.

Eu tive um problema semelhante com o meu aplicativo MEAN. No meu caso, o problema estava acontecendo em apenas uma solicitação get. Eu tentei remover o adblock, tentei limpar o cache e tentei com diferentes navegadores. Nada ajudou.

finalmente, descobri que a API estava tentando retornar um object JSON enorme. Quando tentei enviar um object pequeno, estava funcionando bem. Finalmente, mudei minha implementação para retornar um buffer em vez de um JSON.

Desejo expressJS para lançar um erro neste caso.

Os dados armazenados em cache do histórico do navegador funcionam para mim.

Use este código de punho do seu código:

 header('Cache-Control: no-cache, no-store, must-revalidate'); header('Pragma: no-cache'); header('Expires: 0'); 

Isso funciona para mim.

Esse problema também ocorrerá ao usar alguns pacotes como o webpack-hot-middleware e abrir várias páginas ao mesmo tempo. webpack-hot-middleware cria uma conexão para cada página para ouvir as alterações de código e atualizar a página. Cada navegador tem uma limitação de max-connections-per-server que é 6 para o Chrome, portanto, se você já tiver aberto mais de seis páginas no Chrome, a nova solicitação ficará suspensa até que você feche algumas páginas.

Isso também pode acontecer devido a um novo recurso chamado isolamento do site

Esta página detalha o problema e uma solução alternativa . Que é ir para chrome://flags/#site-isolation-trial-opt-out no Chrome e alterar essa configuração para “Opt-out” e recarregar o Chrome.

É um problema conhecido . No entanto, essa página diz que ela foi corrigida no chrome 68, mas estou executando o chrome 68 e ainda tenho o problema.

Isso pode ser porque você enviou uma solicitação do Ajax, mas agora você pula sua página para outra usando location.href ou algo parecido. Portanto, a solicitação de visualização falhou.