Página HTTPS sem imagens: verifique os endereços dos recursos

A página abre, mas uma parte falha

Publica a página de uma jornada e partilha o endereço HTTPS. O texto aparece, mas falta o cartaz ou uma função não responde. Antes de gerar outro link curto, verifique se a página carrega recursos através de endereços HTTP antigos. O documento principal e os ficheiros necessários são pedidos diferentes. Abrir o primeiro não demonstra que imagens, estilos e programas também foram carregados. Investigue o componente que falha antes de substituir o endereço distribuído.

As perguntas reais consultadas descrevem recursos bloqueados e fotografias ausentes depois de ativar HTTPS. Indicam uma necessidade, não um diagnóstico automático de qualquer imagem danificada. Este guia identifica o pedido concreto, verifica o destino público e corrige a referência com o responsável pela web. WikiURL ajuda a consultar respostas e redirecionamentos; não examina automaticamente cada recurso da página nem reproduz todas as decisões do navegador. Mantenha essa distinção ao interpretar o resultado de uma consulta.

Separe o documento do recurso incorporado

O exemplo apresenta uma página HTTPS e duas variantes do endereço do cartaz. Os domínios são fictícios e não funcionam. A segunda linha representa uma referência HTTP incorporada; a terceira é uma candidata HTTPS a verificar no fornecedor real. Acrescentar uma letra não garante que o ficheiro existe, que o certificado é válido ou que a imagem certa será recebida. Confirme o suporte antes de alterar o material publicado; as amostras servem apenas para comparar a estrutura.

A MDN chama conteúdo misto ao uso de recursos inseguros numa página carregada com segurança. Os navegadores podem atualizar alguns pedidos para HTTPS e bloquear outros. Não suponha que cada imagem HTTP aparecerá, nem que serão todas bloqueadas da mesma maneira. A MDN distingue, por exemplo, nomes de domínio de certas referências com endereço IP. Aqui usamos nomes fictícios e não propomos modificar configurações do navegador. O importante é observar o pedido específico e encontrar uma alternativa segura suportada.

https://example.invalid/evento/
http://media.example.invalid/cartel.jpg
https://media.example.invalid/cartel.jpg

Procure a mensagem antes de escolher a causa

Num navegador de computador, abra as ferramentas de desenvolvimento, consulte a consola e o painel de rede e recarregue a página. Procure o aviso de conteúdo misto e o URL pedido. Registe o tipo de recurso e o erro observado. Se não existir esse aviso, investigue a resposta concreta: um ficheiro ausente ou outra restrição também impede a imagem. A utilização de HTTPS, isoladamente, não torna cada falha num problema de conteúdo misto.

Diferencie a referência escrita no modelo do endereço finalmente solicitado; o navegador pode tentar uma versão atualizada para HTTPS. Não publique capturas com tokens, dados de clientes ou links internos. Se não gere o site, comunique ao responsável a página e o recurso públicos afetados. Não peça aos visitantes que permitam conteúdo inseguro ou desliguem verificações para ver o cartaz. Uma exceção pessoal não corrige a experiência pública nem a referência original; a correção deve acontecer no conteúdo mantido.

Verifique a candidata pública com WikiURL

Se o recurso é público e não contém segredos, utilize o verificador URL do WikiURL para consultar a candidata HTTPS. Reveja o estado HTTP e a URL final detetada; se terminar em HTTP, informe o administrador. Abra depois o recurso no navegador e confirme a imagem correta. Um estado200 pode pertencer a outra página e não certifica, por si só, o funcionamento incorporado. Confira o conteúdo recebido além do número de resposta antes de considerar a alteração validada.

Repita o teste dentro da página original. Uma consulta de servidor e o carregamento contextual do navegador não são equivalentes. Esta verificação WikiURL não fornece inventário de dependências, auditoria de políticas ou reparação do certificado. Não envie recursos privados. Se HTTPS não existe ou falha no fornecedor, peça uma alternativa compatível antes de mudar a referência publicada. Um recurso isolado acessível é evidência útil, mas também é preciso observar a experiência final no contexto previsto para os leitores.

Corrija a referência na origem efetiva

Depois de confirmar a imagem HTTPS, altere a referência no conteúdo, modelo ou configuração que a gera. O exemplo HTML ilustra apenas a substituição: use endereço real autorizado e texto alternativo adequado. web.dev recomenda verificar a disponibilidade segura dos recursos e atualizar ou substituir os que não a oferecem. Guarde uma cópia antes de alterações amplas. Uma edição temporária nas ferramentas do navegador não muda o conteúdo guardado e desaparece ao recarregar; corrija a fonte realmente mantida.

Evite substituições globais sem compreender o armazenamento do gestor. Peça também revisão de recursos produzidos por estilos e extensões. Uma política upgrade-insecure-requests pode ajudar numa migração administrada, mas a MDN explica que a falta da versão HTTPS causa falha sem voltar a HTTP. Não cria HTTPS no servidor de outra entidade nem é uma correção para copiar sem revisão. O suporte do fornecedor e o teste contextual continuam necessários antes de declarar resolvida a experiência de quem visita a página.

<img src="https://media.example.invalid/cartel.jpg" alt="Evento">

Distribua depois de testar a página completa

Recarregue a versão publicada e verifique imagens e ações relevantes nos navegadores previstos. Se houver cache, confirme que observa o conteúdo corrigido. Registe a alteração e o resultado. Um link curto ou QR leva ao destino escolhido, mas não reescreve as referências internas desse destino. Recriá-los sem mudar a página não elimina um pedido inseguro dentro dela. Teste a versão efetivamente publicada, não apenas a pré-visualização do editor antes de guardar; caso contrário, o erro antigo poderá continuar na distribuição.

Depois de verificar a página pública completa, distribua o endereço com WikiURL e teste o link ou QR final. Se uma dependência falhar futuramente, conserve o registo para o responsável localizar a mudança. Separe três testes: chegar à página, obter os recursos necessários e confirmar a experiência real do leitor. O sucesso de um não demonstra o dos restantes. Essa separação torna a verificação útil sem tratar o encurtador como depurador de navegador ou serviço de manutenção automática do site de destino.