#HTTPS/ HTTP

10 messages · Page 1 of 1 (latest)

radiant nacelle
wet echoBOT
#

Hi @radiant nacelle. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

L’erreur que vous rencontrez est liée au “Mixed Content” : votre page est chargée en HTTPS, mais tente de précharger (prefetch) une ressource en HTTP. Les navigateurs modernes bloquent ce type de requête pour des raisons de sécurité, car charger du contenu non sécurisé (HTTP) sur une page sécurisée (HTTPS) peut exposer les utilisateurs à des attaques.

Dans le contexte d’Astro, le système de prefetch va essayer de précharger les liens internes de votre site. Si certains liens utilisent le protocole HTTP au lieu de HTTPS, cela provoque exactement ce type d’erreur. Pour éviter ce problème :

  • Assurez-vous que tous les liens internes utilisés pour le prefetch (par exemple, dans les attributs href de vos balises <a>) utilisent bien le protocole HTTPS.
  • Vérifiez la configuration de votre site/de votre hébergement pour que toutes les URLs générées ou utilisées soient en HTTPS, surtout si vous avez des redirections ou des environnements de staging.
  • Si vous utilisez des stratégies de prefetch globales (par exemple, prefetchAll: true), cela peut amplifier le problème si des liens HTTP sont présents dans le HTML généré ou dans les données dynamiques.

Astro ne gère pas directement la correction de ce problème : il s’agit d’un souci de cohérence des URLs dans votre contenu ou votre configuration. Il n’y a pas d’option dans Astro pour forcer le protocole des liens préfetchés, donc la solution est de corriger la source des URLs pour qu’elles soient toutes en HTTPS.

Pour plus d’informations sur le fonctionnement du prefetch dans Astro, vous pouvez consulter la documentation officielle : Prefetch Guide.

#

En résumé :
Corrigez toutes les URLs internes pour qu’elles utilisent HTTPS afin d’éviter les erreurs de “Mixed Content” lors du prefetch.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@radiant nacelle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

radiant nacelle
#

referer
https://staging.actinmad.art/LeMag/
sec-ch-ua
"Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"
sec-ch-ua-mobile
?0
sec-ch-ua-platform
"Linux"
sec-purpose
prefetch
user-agent
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36

Request call stack
l @ ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js:1
(anonymous) @ ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js:1
setTimeout
t @ ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js:1
Request initiator chain
https://staging.actinmad.art/_astro/router.WLLD8StG.js
https://staging.actinmad.art/LeMag
http://staging.actinmad.art/LeMag/
https://staging.actinmad.art/LeMag/
https://staging.actinmad.art/_astro/ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js
https://staging.actinmad.art/articles/le-test

i'm preety sure it's astro problem don't you think ?

#

@wet echo
referer
https://staging.actinmad.art/LeMag/
sec-ch-ua
"Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"
sec-ch-ua-mobile
?0
sec-ch-ua-platform
"Linux"
sec-purpose
prefetch
user-agent
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36

Request call stack
l @ ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js:1
(anonymous) @ ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js:1
setTimeout
t @ ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js:1
Request initiator chain
https://staging.actinmad.art/_astro/router.WLLD8StG.js
https://staging.actinmad.art/LeMag
http://staging.actinmad.art/LeMag/
https://staging.actinmad.art/LeMag/
https://staging.actinmad.art/_astro/ClientRouter.astro_astro_type_script_index_0_lang.B0JFCTGp.js
https://staging.actinmad.art/articles/le-test

i'm preety sure it's astro problem don't you think ?

wet echoBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources provided, Astro’s prefetching system will prefetch internal links using the URLs present in your site’s HTML. The error you are seeing—where a page loaded over HTTPS tries to prefetch a resource over HTTP—results in a “Mixed Content” warning, which is a browser security feature and not a bug in Astro itself.

Astro’s documentation specifies that prefetching only works for links within your site and does not mention any automatic protocol correction or rewriting for prefetch URLs. The prefetch script will use the URLs as they appear in your <a href="..."> attributes or as generated by your site’s routing logic. If any of these URLs are HTTP instead of HTTPS, the browser will block the prefetch request when the page is served over HTTPS, resulting in the error you described. This is expected browser behavior and not an Astro-specific bug Prefetch Guide.

To resolve this, you should ensure that all internal links in your site use HTTPS. This may involve:

  • Checking your content, templates, and data sources to ensure all URLs are HTTPS.
  • Reviewing any dynamic link generation logic to enforce HTTPS.
  • Ensuring your deployment and environment configuration do not generate or rewrite URLs to HTTP.

Astro does not provide a built-in mechanism to rewrite HTTP links to HTTPS for prefetching. The documentation is clear that prefetching is enabled for internal links as they are written, and does not mention protocol handling or correction Prefetch Options.

In summary:
This is not an Astro bug, but a result of how your site’s URLs are generated or written. You need to ensure all internal links use HTTPS to avoid mixed content errors during prefetching.

#

If you need more details on how prefetching works with view transitions or the <ClientRouter />, see Using with View Transitions.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: