Puis-je changer tous mes liens http:// en seulement // ?

Question

Dave Ward dit,

Ce n'est pas exactement une lecture légère, mais section 4.2 du RFC 3986 permet de créer des URL entièrement qualifiées sans protocole (HTTP ou HTTPS). Lorsque le protocole d'une URL est omis, le navigateur utilise le protocole du document sous-jacent à la place.

En bref, ces URL "sans protocole" permettent à une référence comme celle-ci de fonctionner dans tous les navigateurs que vous utiliserez :

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

Cela peut paraître étrange au premier abord, mais cette URL "sans protocole" est le meilleur moyen de référencer le contenu d'un tiers qui est disponible à la fois via HTTP et HTTPS.

Cela résoudrait certainement un grand nombre d'erreurs de contenu mixte que nous voyons sur les pages HTTP - en supposant que nos ressources soient disponibles à la fois via HTTP et HTTPS.

Est-ce que c'est complètement compatible avec les différents navigateurs ? Y a-t-il d'autres inconvénients ?

Answer 1

Je l'ai testé minutieusement avant de le publier. Parmi tous les navigateurs disponibles pour tester sur Browshots je n'en ai trouvé qu'un seul qui ne gérait pas correctement l'URL relative au protocole : un obscur navigateur *nix appelé Dillo .

Il y a deux inconvénients sur lesquels j'ai reçu des commentaires :

1. Les URL sans protocole peuvent ne pas fonctionner comme prévu lorsque vous "ouvrez" un fichier local dans votre navigateur, car le protocole de base de la page sera file:///. C'est particulièrement vrai lorsque vous utilisez l'URL sans protocole pour une ressource externe, comme une ressource hébergée par un CDN. Utilisation d'un serveur web local comme Apache ou IIS pour effectuer le test http://localhost Les adresses fonctionnent pourtant bien.
2. Apparemment, il existe au moins une application de lecteur de flux pour iPhone qui ne gère pas correctement les URL sans protocole. Je ne sais pas laquelle a ce problème ni quelle est sa popularité. Pour l'hébergement d'un fichier JavaScript, ce n'est pas un gros problème puisque les lecteurs RSS ignorent généralement le contenu JavaScript de toute façon. Toutefois, cela pourrait poser problème si vous utilisez ces URL pour des médias tels que des images à l'intérieur d'un contenu qui doit être syndiqué via RSS (bien que cette seule application de lecteur sur une seule plate-forme représente probablement un nombre très marginal de lecteurs).

Answer 2

La question de savoir si l'on pourrait changer tous leurs liens pour qu'ils soient relatifs au protocole peut être discutable, si l'on considère la question de savoir si l'un devrait le faire. Selon Paul Irish :

2014.12.17 : Maintenant que SSL est encouragé pour tout le monde et ne pose pas de problème de performance, cette technique est désormais un anti-modèle. Si le ressource dont vous avez besoin est disponible sur SSL, alors toujours utiliser le https:// atout.

Answer 3

Si vous utilisez des URL sans protocole pour charger les feuilles de style, IE 7 et 8 les téléchargeront deux fois : http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

C'est donc à éviter pour les CSS si vous aimez les bonnes performances.

Answer 4

Oui, les références aux chemins d'accès au réseau étaient déjà spécifiées dans le document RFC 1808 et devrait fonctionner avec tous les navigateurs.

Answer 5

Ce site est-il entièrement compatible avec les différents navigateurs ? Y a-t-il d'autres inconvénients ?

Si vous développez sur un serveur local, cela peut ne pas fonctionner. Vous devez spécifier un schéma, sinon le navigateur peut supposer que src="//cdn.example.com/js_file.js" es src="file://cdn.example.com/js_file.js" ce qui ne fonctionnera pas puisque vous n'hébergez pas cette ressource localement.

Microsoft Internet Explorer semble être particulièrement sensible à ce problème, voir cette question : Impossible de charger jQuery dans Internet Explorer sur localhost (WAMP)

Vous essayerez probablement toujours de trouver une solution qui fonctionne dans tous vos environnements avec le moins de modifications possible.

La solution utilisée par HTML5Boilerplate est d'avoir une solution de repli lorsque la ressource n'est pas chargée correctement, mais cela ne fonctionne que si vous incorporez une vérification :

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

J'ai posté cette réponse aquí également.

UPDATE : HTML5Boilerplate utilise maintenant <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"> après avoir décidé de déprécier les URL relatifs au protocole, voir aquí .