Y at-il inconvénient à l'aide d'un premier double barre oblique pour hériter du protocole dans une URL? dire src = « // domain.com »

Question

J'ai une feuille de style qui charge les images à partir d'un domaine externe et j'ai besoin de charger à partir https: // à partir des pages de commande sécurisées et http: // d'autres pages, en fonction de l'URL actuelle. J'ai trouvé que l'URL commençant par une double barre oblique hérite du protocole actuel. Est-ce que tous les navigateurs prennent en charge cette technique?

html ex:

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

ex css:

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

Answer 1

Si les supports de navigateur RFC 1808 Section 4 , RFC 2396 section 5.2 ou RFC 3986 section 5.2 , il sera en effet utiliser le schéma de l'URL de la page pour les références commençant par « //".

Answer 2

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

Mise à jour à partir de 2014:

  

Maintenant que SSL est encouragé pour tout le monde et ne sont pas les problèmes de performances , cette technique est maintenant un anti-modèle . Si l'actif dont vous avez besoin est disponible sur SSL, puis toujours utiliser l'actif https://.

Answer 3

Un inconvénient se produit si vos URL sont considérées en dehors du contexte d'une page Web. Par exemple, un message électronique assis dans un client de messagerie (par exemple, Outlook) a effectivement pas l'URL, et lorsque vous affichez un message contenant une URL de protocole relatif, il n'y a pas de contexte de protocole évident du tout (le message lui-même est indépendant du protocole utilisé pour la prendre, que ce soit POP3, IMAP, Exchange, uucp ou autre) si l'URL a aucun protocole être par rapport à. J'ai pas la compatibilité avec les clients étudié email pour voir ce qu'ils font lorsqu'ils sont présentés avec un gestionnaire de protocole manquant - je suppose que la plupart prendra une estimation à l'adresse http. Apple Mail refuse de vous laisser entrer une URL sans protocole. Il est analogue à la façon dont les URL relatives ne fonctionnent pas dans le courrier électronique en raison d'un contexte de la même manquante.

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

L'explication plus générale est que les URL de protocole anonymes ne peuvent pas travailler en vase clos; il doit un contexte pertinent. Dans une page web typique, il est donc bien de tirer dans une bibliothèque de scripts de cette façon, mais tous les liens externes doit toujours spécifier un protocole. J'ai essayé un test simple:. //stackoverflow.com cartes à file:///stackoverflow.com dans tous les navigateurs je l'ai essayé, donc ils vraiment ne fonctionnent pas par eux-mêmes

Answer 4

La raison pourrait être de fournir des pages Web portables. Si la page externe n'est pas transporté crypté (http), pourquoi doivent être chiffrés les scripts liés? Cela semble être une perte de performance inutile. Dans le cas, la page externe est crypté sécurisé durant le transport (https), le contenu doit être lié trop chiffré,. Si la page est cryptée, le contenu lié non, IE semble émettre un Contenu mixte avertissement. La raison en est qu'un attaquant peut manipuler les scripts sur le chemin. Voir http://ie.microsoft.com/testdrive/Browser/ MixedContent / Default.html? o = 1 pour une discussion plus longue.

Le HTTPS Everywhere campagne du FEP suggère d'utiliser https chaque fois que possible. Nous avons la capacité de serveur ces jours-ci pour servir des pages web toujours crypté.

Answer 5

Juste pour être complet. Cela a été mentionné dans un autre thread:

  

'Les deux barres obliques avant sont un raccourci commun pour tout protocole   est utilisé à droite '

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

S'il vous plaît vérifier le fil complet.

Answer 6

Il semble être une technique assez courante maintenant. Il n'y a aucun inconvénient, il aide seulement à unifier le protocole pour l'ensemble des actifs sur la page devrait donc être utilisé chaque fois que possible.