web-dev-qa-db-fra.com

Ajout de liens: puis-je utiliser // domaine (double barre oblique) pour https: // et http: //

Nous passons bientôt à https. Je comprends qu’il est judicieux d’utiliser //domain.com liens et images src références.

  • Le navigateur essaie-t-il d'abord https? et si pas trouvé http?
  • Est-ce supporté par tous les navigateurs?

En fin de compte, tous les liens du site doivent-ils utiliser //domain.com (avec double barre oblique)?

Et Google comprend-il (et suit-il) //domain.com liens?

urlhttpslinksrelative-urls
6
snh_nl

Les navigateurs n'essayent pas un protocole puis retombent sur l'autre. Le navigateur utilisera le protocole auquel il est lié. Si ce protocole n'est pas pris en charge, l'utilisateur recevra une erreur.

Si vous voulez obliger les utilisateurs à utiliser un protocole, vous pouvez rediriger l'un vers l'autre. Par exemple, pour forcer la connexion sécurisée sur votre site, utilisez la règle de réécriture suivante dans votre . Htaccess . Il émettra des redirections 301 de http://example.com/page.html vers https://example.com/page.html ( source )

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

Il semblerait que vous souhaitiez autoriser les utilisateurs à utiliser l’un ou l’autre et à les laisser rester sur celui de leur choix. C'est bon. Il existe plusieurs façons de mettre en forme des liens relatifs sur votre site pour vous aider. Utiliser // n’est pas celui que je recommanderais.

Si votre utilisateur est sur https://example.com/foo.html et que vous voulez qu'il accède à https://example.com/bar.html, l'un des éléments suivants href fonctionnera dans la balise a:

  • URL complète - https://example.com/bar.html - Si l'utilisateur est sur le site http, il sera redirigé vers le https site.
  • Protocole relatif - //example.com/bar.html - L'utilisateur sera dirigé vers https://example.com/bar.html ou http://example.com/bar.html en fonction de celui qui protocole qu'ils utilisent actuellement.
  • Relatif au site - /bar.html - Le protocole et le nom de domaine restent identiques, le chemin complet de l'URL change.
  • Répertoire relatif - bar.html - Remplace la partie du document dans l'URL (tout après la dernière barre oblique).

Je recommande d'utiliser des liens relatifs de site qui commencent la plupart du temps par une barre oblique lorsque vous créez un lien vers d'autres éléments de votre site. Comme pour les URL relatives au protocole, les utilisateurs utiliseront les mêmes http ou https qu’ils utilisent actuellement. C'est beaucoup moins de frappe (et rend les pages plus petites) que d'utiliser des URL complètes ou des URL relatives au protocole.

Les URL relatives aux répertoires peuvent également fonctionner, mais elles peuvent être délicates dans quelques cas:

  • La liaison de example.com/bar/foo.html à example.com/bar/ est délicate. L'URL relative du répertoire pour cela est ./ où . signifie le répertoire actuel. L'URL relative au site est simplement /bar/.
  • La liaison au répertoire suivant utilise la notation ... Donc, pour relier example.com/bar/foo.html à example.com/baz.html, le lien serait ../baz.html Le lien relatif au serveur serait simplement /baz.html.

Vous pouvez utiliser des liens relatifs de répertoire pour créer des liens vers d'autres documents connus pour figurer dans le répertoire actuel et utiliser des liens relatifs de site pour créer des liens vers JS, CSS et des images qui se trouvent généralement à la racine du site ou à proximité.

Les directives relatives au protocole sont particulièrement utiles pour les liens vers les autres sites où vous souhaitez conserver le protocole. Je l’utilise le plus souvent pour du JavaScript ou des images de tiers. S'ils ne sont pas récupérés de manière sécurisée, lorsque mon utilisateur est sécurisé, il reçoit un avertissement. Si mon utilisateur n'est pas sécurisé, il se peut que mon site soit plus lent à extraire les ressources d'autres sites en toute sécurité. Par exemple, si vous utilisiez des données de devise de mon site de conversion de devise, vous pouvez créer un lien vers son JavaScript tiers, tel que <script src="//coinmill.com/frame.js"></script>.

Tous les navigateurs et moteurs de recherche modernes prennent en charge tous ces types de liens.

9
Stephen Ostermiller

// signifie fondamentalement qu'une ressource sera demandée dans le même protocole. Ainsi, si quelqu'un navigue sur httpS://yourwebsite.com, et que vous incluez une feuille de style comme //yourwebsite.com/style.css, elle se chargera httpS://yourwebsie.com/style.css .

Si vous demandez des ressources à http lorsque la page est https, le navigateur peut générer une erreur.

Pour répondre à vos questions:

Le navigateur essaie-t-il d'abord https? et si pas trouvé http?

Non, si le // n'est pas trouvé, il renverra simplement le code d'état HTTP suffisant.

Est-ce supporté par tous les navigateurs?

Autant que je sache, tous les navigateurs le supportent, mais ne vous fiez pas à ma parole ...

3
William Edwards

À https://developers.google.com/speed/libraries/devguide Google recommande d'utiliser <script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script> pour créer un lien vers jQuery, par exemple. Google héberge les bibliothèques jQuery à la fois en http et en https. Le navigateur utilisera le même protocole que celui utilisé pour accéder à votre site afin de récupérer le code JavaScript inclus. Il ne tentera pas l'un puis l'autre! Vous ne voulez pas que le site devienne soudainement non sécurisé, car une ressource ne peut être trouvée que via http! Cela présente l’avantage de ne pas utiliser une connexion sécurisée uniquement pour JS si votre site est en cours d’accès via http et de ne pas vous avertir que certaines ressources ne sont pas sécurisées si votre site est en cours d’accès via https.

Il est probablement préférable d’utiliser cette méthode (//domain.tld/) pour les ressources externes si votre site bascule de http à https (par exemple, utilisateur connecté/non connecté). Si vous utilisez toujours http, vous n'en avez pas besoin, si vous utilisez toujours https, vous n'en avez pas besoin car vous pouvez simplement coder en dur le même protocole dans vos URL, mais cela ne fera pas de mal.

Vous n'en aurez pas besoin pour les ressources internes si vous utilisez des URL relatives, car le navigateur utilisera le même protocole.

2
CJ Dennis