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


148

J'ai une feuille de style qui charge les images d'un domaine externe et j'en ai besoin pour charger à partir de https: // à partir de pages de commande sécurisées et http: // à partir d'autres pages, en fonction de l'URL actuelle. J'ai trouvé que démarrer l'URL avec 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); }

1
est-ce que cela ralentit le site ???
TheBlackBenzKid

2
il n'y a aucune raison que cela ait un impact sur les performances, sauf dans les cas mentionnés ci-dessous par Meder dans sa réponse.
Rob Volk

On dirait que j'étais sur quelque chose. Il y a quelques mois, les développeurs de Google ont commencé à utiliser cette convention sur leur page de bibliothèques JavaScript hébergées developer.google.com/speed/libraries/devguide
Rob Volk

10
Et si un tel fichier HTML est chargé localement (ouvert directement avec le navigateur)? On dirait que Firefox (28 dans ce cas) ne charge pas la ressource distante. Cela a du sens, car alors HTTP n'est pas le protocole parent. Mais ce serait un inconvénient, à mon avis.
Dr.Jan-Philip Gehrcke

Réponses:


86

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


8
est-ce pris en charge sur tous les principaux navigateurs? (IE7, IE8, FF, Chrome, Safari)
Rob Volk

22
Étant donné que la première RFC à la décrire, la RFC 1808, a été écrite il y a 15 ans et que les références d'URL sont essentielles à la fonctionnalité du site Web, je pense qu'il est prudent de dire que presque tous les principaux navigateurs la prennent désormais en charge. Mais le seul moyen d'en être sûr est de simplement l'essayer vous-même et de voir ce qui se passe.
Remy Lebeau

2
Cette question était liée à quelqu'un posant une question similaire, et je l'ai trouvée dans la RFC 1630 l'année précédente (énoncé différemment, mais autorisant toujours le format en question). Cela aurait pu être sous une forme ou une autre du document qui existait à ftp://info.cern.ch/pub/www/doc/http-spec.txtpartir de 1991, si quelqu'un avait une copie d'archive.
Jon Hanna

4
"2014.12.17: Maintenant que SSL est encouragé pour tout le monde et n'a pas de problèmes de performances, cette technique est désormais un anti-pattern. Si l'actif dont vous avez besoin est disponible sur SSL, utilisez toujours l'actif https: //." (citation tirée de stackoverflow.com/a/27999789 )
joonas.fi

@ joonas.fi Ce raisonnement est de deuxième ordre. SSL a toujours des impacts sur les performances et n'est pas nécessaire dans un grand nombre d'applications. Je préfère l'utiliser, bien sûr, mais je ne voudrais pas que cela soit appliqué, par exemple, dans le code que je déploie.
Otheus

64

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

Mise à jour de 2014:

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


18
Corrigé dans IE9, FWIW.
EricLaw

@EricLaw est-ce que cela est corrigé dans IE9 quel que soit le mode de rendu ou uniquement en mode Standards et toujours interrompu en mode Quirks?
scunliffe

Je suis presque sûr que cela a été corrigé dans tous les modes du scanner lookahead. Avez-vous vu autrement quelque part?
EricLaw

SSL certainement fait un impact sur les performances. L'EFF n'écrit pas d'interfaces serveur-serveur, et cet autre site a peu d'expertise technique. En outre, il est anti-modèle de supposer que le fournisseur d'un site Web appliquera de telles restrictions. Ainsi, les gens qui écrivent des applications CSS et javascript ne doivent pas miser sur la question du protocole.
Otheus

63

Un inconvénient se produit si vos URL sont affichées en dehors du contexte d'une page Web. Par exemple, un message électronique assis dans un client de messagerie (par exemple, Outlook) n'a en fait aucune URL, et lorsque vous affichez un message contenant une URL relative au protocole, il n'y a pas du tout de contexte de protocole évident (le message lui-même est indépendant du protocole utilisé pour le récupérer, que ce soit 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 présentés avec un gestionnaire de protocole manquant - je suppose que la plupart prendront une estimation à http. Apple Mail refuse de vous laisser entrer une URL sans protocole. C'est analogue à la façon dont les URL relatives ne fonctionnent pas dans les e-mails en raison d'un contexte également manquant.

Des problèmes similaires peuvent survenir dans d'autres contextes non HTTP tels que les tweets, les messages SMS, les documents Word, etc.

L'explication la plus générale est que les URL de protocole anonymes ne peuvent pas fonctionner isolément; il doit y avoir un contexte pertinent. Dans une page Web typique, il est donc très bien d'extraire une bibliothèque de scripts de cette façon, mais tous les liens externes doivent toujours spécifier un protocole. J'ai essayé un test simple: des //stackoverflow.comcartes file:///stackoverflow.comdans tous les navigateurs dans lesquels j'ai essayé, donc elles ne fonctionnent vraiment pas toutes seules.


5
C'est un très bon point, j'y pensais en fait lorsque je me suis endormi la nuit dernière. Un autre problème est que la version httpsou httppeut ne pas être réellement disponible, vous ne pouvez pas toujours supposer que c'est le cas.
Wesley Murch

1
En dehors d'un navigateur, vous êtes seul, pour ainsi dire. Il n'y a aucun moyen de dire si l'e-mail ou un autre client connaît javascript ou css, etc. Donc c'est à peu près un point discutable sur les URL relatives?
chris

Pas un point discutable. De nombreux clients de messagerie prennent en charge JS et les navigateurs le peuvent certainement lors du chargement à partir de file://. C'est un cas d'utilisation mineur, mais quand il se présente, c'est important.
Jun-Dai Bates-Kobashigawa

Je souhaite qu'il y ait un moyen de spécifier use http sauf si l'url actuelle est https, auquel cas utilisez https , plutôt que de spécifier utiliser le même protocole que celui avec lequel les pages actuelles ont été chargées , ce qui est effectivement ce qui //est.
Jun-Dai Bates-Kobashigawa

2
Si vous spécifiez un par exemple <base href="https://www.google.com">, vous pouvez afficher le contenu en dehors du côté Web. soit <img src="//www.google.com/images/srpr/logo11w.png">ou<img src="images/srpr/logo11w.png">
zig

3

La raison pourrait être de fournir des pages Web portables. Si la page externe n'est pas transportée chiffrée (http), pourquoi les scripts liés devraient-ils être chiffrés? Cela semble être une perte de performances inutile. Dans le cas où la page externe est cryptée de manière sécurisée (https), le contenu lié doit également être crypté. Si la page est chiffrée, le contenu lié non, IE semble émettre un avertissement de contenu mixte . La raison en 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.

La campagne HTTPS Everywhere de l'EFF suggère d'utiliser le https dans la mesure du possible. Nous avons la capacité de serveur de nos jours pour servir des pages Web toujours cryptées.



-2

Cela semble être une technique assez courante maintenant. Il n'y a pas d'inconvénient, cela aide uniquement à unifier le protocole pour tous les éléments de la page et doit donc être utilisé dans la mesure du possible.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.