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

Dave Ward dit:

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

En termes simples, ces URL «sans protocole» permettent à une référence comme celle-ci de fonctionner dans tous les navigateurs dans lesquels vous l'essayerez:

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

Cela semble étrange au début, mais cette URL «sans protocole» est le meilleur moyen de référencer le contenu tiers disponible via HTTP et HTTPS.

Cela résoudrait certainement un tas d'erreurs de contenu mixte que nous voyons sur les pages HTTP - en supposant que nos actifs sont disponibles via HTTP et HTTPS.

Est-ce complètement compatible avec tous les navigateurs? Y a-t-il d'autres mises en garde?

Je l'ai testé à fond avant de publier. De tous les navigateurs disponibles pour effectuer des tests sur Browsershots , je n'ai pu en trouver qu'un qui ne gérait pas correctement l'URL relative du protocole: un navigateur obscur * 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: ///. Surtout lorsque vous utilisez l'URL sans protocole pour une ressource externe comme un actif hébergé sur CDN. L'utilisation d'un serveur Web local comme Apache ou IIS pour tester les adresses http: // localhost fonctionne bien cependant.
2. Apparemment, il existe au moins une application de lecture de flux iPhone qui ne gère pas correctement les URL sans protocole. Je ne sais pas lequel a le problème ni à quel point il est populaire. Pour l'hébergement d'un fichier JavaScript, ce n'est pas un gros problème car les lecteurs RSS ignorent généralement le contenu JavaScript de toute façon. Cependant, cela pourrait être un problème si vous utilisez ces URL pour des médias comme des images dans du contenu qui doit être syndiqué via RSS (cependant, cette application à lecteur unique sur une seule plate-forme représente probablement un nombre très marginal de lecteurs).

La question de savoir si l'on peut modifier tous leurs liens pour qu'ils soient liés au protocole peut être théorique, compte tenu de la question de savoir si l'on doit le faire. Selon Paul Irish :

2014.12.17: Maintenant que SSL est encouragé pour tout le monde et n'a pas de soucis de performances, cette technique est maintenant un anti-pattern. Si l'actif dont vous avez besoin est disponible sur SSL, utilisez toujours l' actif https: // .

Si vous utilisez des URL sans protocole pour charger des 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/

Donc, cela doit être évité pour CSS si vous aimez les bonnes performances.

Oui, les références de chemin de réseau étaient déjà spécifiées dans la RFC 1808 et devraient fonctionner avec tous les navigateurs.

Est-ce complètement compatible avec tous les navigateurs? Y a-t-il d'autres mises en garde?

Juste pour jeter cela dans le mélange, si vous développez sur un serveur local, cela pourrait ne pas fonctionner. Vous devez spécifier un schéma, sinon le navigateur peut supposer que tel src="//cdn.example.com/js_file.js"est le cas src="file://cdn.example.com/js_file.js", car il ne fonctionnera pas car vous n'hébergez pas cette ressource localement.

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

Vous essayerez probablement toujours de trouver une solution qui fonctionne sur tous vos environnements avec le moins de modifications nécessaires.

La solution utilisée par HTML5Boilerplate est d'avoir un 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 également posté cette réponse ici .

MISE À JOUR: HTML5Boilerplate utilise désormais <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 relatives du protocole, voir ici .

Je n'ai pas eu ces problèmes lors de l'utilisation de: //domain.com - mais vous devez ajouter les deux points au début. Yoast a eu un bon article à ce sujet il y a quelque temps. Mais c'est perdu dans sa pile de billets de blog.

Si vous souhaitez vous assurer que toutes les demandes sont mises à niveau vers un protocole sécurisé, il existe une option simple pour utiliser les demandes de mise à niveau-non sécurisées de l'en- tête de la politique de sécurité du contenu

Content-Security-Policy: upgrade-insecure-requests;

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests