Y a-t-il un inconvénient à utiliser une double barre oblique pour hériter du protocole dans une URL ? Par exemple, src="//domaine.com".

Question

J'ai une feuille de style qui charge des images à partir d'un domaine externe et j'ai besoin qu'elle charge https:// à partir des pages de commandes sécurisées et http:// à partir d'autres pages, en fonction de l'URL actuelle. J'ai découvert que le fait de commencer l'URL par une double barre oblique hérite du protocole actuel. Tous les navigateurs prennent-ils en charge cette technique ?

html ex :

<img src="//cdn.domain.com/logo.png" />

css ex :

.class { background: url(//cdn.domain.com/logo.png); }

Answer 1

Si le navigateur prend en charge RFC 1808 Section 4 , RFC 2396 Section 5.2 ou RFC 3986 Section 5.2 alors il utilisera effectivement le schéma de l'URL de la page pour les références qui commencent par "//".

Answer 2

Lorsqu'il est utilisé sur un link o @import IE7/IE8 téléchargera le fichier deux fois par jour. http://paulirish.com/2010/the-protocol-relative-url/

Mise à jour de 2014 :

Maintenant que SSL est encouragé pour tous y n'a pas de problème de performance , cette technique est désormais un anti-modèle . Si le bien dont vous avez besoin est disponible sur SSL, alors toujours utiliser le https:// atout.

Answer 3

Un inconvénient se présente si vos URL sont consultées en dehors du contexte d'une page web. Par exemple, un message électronique se trouvant dans un client de messagerie (disons Outlook) n'a effectivement pas d'URL, et lorsque vous visualisez un message contenant une URL relative au protocole, il n'y a aucun contexte de protocole évident (le message lui-même est indépendant du protocole utilisé pour le récupérer, qu'il s'agisse de POP3, IMAP, Exchange, uucp ou autre), de sorte que l'URL n'a pas de protocole auquel être relative. Je n'ai pas étudié la compatibilité avec les clients de messagerie pour voir ce qu'ils font lorsqu'ils sont confrontés à un gestionnaire de protocole manquant - je suppose que la plupart d'entre eux se contenteront de http. Apple Mail refuse de vous laisser entrer une URL sans protocole. C'est analogue à la manière dont les URL relatives ne fonctionnent pas dans le courrier électronique en raison de l'absence d'un contexte similaire.

Des problèmes similaires pourraient se produire dans d'autres contextes non HTTP, comme dans les tweets, les messages SMS, les documents Word, etc.

L'explication plus générale est que les URL de protocole anonymes ne peuvent pas fonctionner de manière isolée ; il y a doit être un contexte pertinent. Dans une page web typique, il est donc possible de faire entrer une bibliothèque script de cette façon, mais tout lien externe doit toujours spécifier un protocole. J'ai fait un test simple : //stackoverflow.com mapas a file:///stackoverflow.com dans tous les navigateurs dans lesquels je l'ai essayé, donc ils realmente ne fonctionnent pas toutes seules.

Answer 4

La raison pourrait être de fournir des pages web portables. Si la page extérieure n'est pas transportée de manière cryptée (http), pourquoi les scripts liés devraient-ils être cryptés ? Cela semble être une perte de performance inutile. Dans le cas où la page extérieure est transportée de manière sécurisée et cryptée (https), alors le contenu lié devrait être crypté également. Si la page est cryptée et que le contenu lié ne l'est pas, IE semble émettre un message d'erreur Contenu mixte avertissement. La raison est qu'un attaquant peut manipuler les scripts en cours de route. Voir http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 pour une discussion plus longue.

En HTTPS partout La campagne de l'EFF suggère d'utiliser le protocole https chaque fois que possible. De nos jours, nous disposons de la capacité de serveur nécessaire pour servir des pages web toujours cryptées.

Answer 5

Juste pour être complet. Cela a été mentionné dans un autre fil de discussion :

Les "deux barres obliques" sont un raccourci commun pour "le protocole utilisé en ce moment".

if (plain http environment) {
    use 'http://example.com/my-resource.js'
} else {
    use 'https://example.com/my-resource.js'
}

Veuillez consulter le fil de discussion complet.