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


240

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?


Il y a quelque temps, j'ai lu sur cette technique sur le blog IE. Mais quand j'ai essayé ça ne marchait pas très bien. Si mon site était servi avec HTTPS, le navigateur (Chrome) utilisait toujours HTTP pour les URL sans protocole.
Christopher Ramírez

10
AVERTISSEMENT: pensez à ne JAMAIS utiliser d'URI sans schéma dans les redirections HTTP 3xx !! Les en-têtes HTTP ne sont pas compatibles avec ce format d'URL. Si vous devez rediriger en fonction du schéma, utilisez mod_rewrite ou similaire.
user2596282

1
@ user2596282 L'expérimentation dans les versions modernes de Chrome et Firefox n'est pas d'accord avec vous, tout comme la révision (toujours en projet) de HTTP 1.1. spécification définie par le groupe de travail HTTPbis (voir svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Peut-être que ce que vous dites est vrai pour certains navigateurs; en connaissez-vous en particulier qui échouent sur les URL relatives au protocole dans les en-têtes d'emplacement?
Mark Amery


Ne les utilisez pas, ils sont moches et redondants.
IllidanS4 veut que Monica revienne

Réponses:


204

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).

33
Alors que IE7 / 8 gère bien les URL relatives au protocole (alias URI sans schéma) dans la plupart des cas, lorsque des feuilles de style sont spécifiées avec de telles URL, il les télécharge deux fois . (Ainsi dit Steve Souders )
lucasrizoli

3
Je constate qu'IE6 tente de convertir l'URI en un URI relatif (c'est-à-dire en supprimant l'une des barres obliques principales). C'est dans un linkélément. Par exemple, lors de la spécification //fonts.googleapis.com/css?family=Rokkitt:400,700, IE6 essaie de se charger http://mysite.com/fonts.googleapis.com/css/<...>. Pas si bon!
CBono

2
J'ai trouvé dans mes journaux des exemples de ce qui semble être des robots web spider (source inconnue) essayant d'utiliser les liens sans protocole et ne les gérant pas correctement également.
Kzqai

3
J'en ai vu beaucoup dans mes journaux, sans rapport avec les URL sans protocole. Beaucoup de ces araignées sont incroyablement mal écrites.
Dave Ward

11
Il est important de comprendre que ces URL sont pas du protocole utilisé moins , mais du protocole utilisé par rapport . Ils obtiennent leur protocole à partir de leur contexte et, faute de contexte, ils agiront comme des URL de fichier dans la plupart des navigateurs, ce qui signifie effectivement qu'ils se brisent en ne chargeant pas le contenu prévu. Bien qu'ils fonctionnent lorsqu'ils sont livrés via http, vous constaterez que si vous enregistrez la page et chargez exactement le même HTML à partir d'un fichier local, ils ne fonctionneront pas, car le contexte est différent. Les seuls contextes dans lesquels vous devez les utiliser sont http vs https.
Synchro

37

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: // .


Je pensais exactement la même chose. Quel est l'intérêt de télécharger un actif externe sur http s'il est également disponible sur https - même si le site principal utilise http (ce qu'il ne devrait pas, mais c'est un autre sujet).
joonas.fi

1
@ joonas.fi la seule chose à laquelle je peux penser est d'éviter les avertissements mixtes HTTP / HTTPS qui pourraient être générés par certains navigateurs
Ohad Schneider

3
Les avertissements @Ohad_Schneider ne sont déclenchés que si le document est chargé via sécurisé (https) mais les actifs via non sécurisé (http). Ce que je suggérais, c'est que vous pouvez toujours charger des actifs sur sécurisé, même si le document est chargé sur non sécurisé. Il n'y a aucun avertissement et aucune raison de ne pas utiliser sécurisé, ce qui rend inutile toute l'URL relative au protocole.
joonas.fi

1
@Ohad_Schneider oh désolé, je pense que j'ai mal interprété ce que vous disiez. Le chargement d'actifs sur https lorsque votre document est sur http ne devrait pas générer d'avertissement. Mais le chargement d'actifs sur http lorsque votre document est sur https le fait (et est probablement bloqué par défaut, au moins dans Chrome). Faites-vous référence au cas où vous servez votre site via https et où les ressources externes ne sont disponibles que sous http? Oui, cela pourrait être un problème, mais je ne pense pas qu'il existe un service tiers sérieux qui ne serve pas leur contenu via https, sinon ils devraient de toute façon cesser leurs activités. :)
joonas.fi

@ joonas.fi Wut? O_o Si quelqu'un a un site HTTPSed (alors) les URL relatives au protocole n'aideront pas à résoudre l'obtention de ressources tierces via HTTP - pas question. Et de toute façon, il vaut mieux ne pas avoir ce logo SSL vert sur votre page HTTPS que de le redonner au HTTP à nouveau, car les tiers ne prennent pas encore en charge le HTTPS.
poige


15

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.


11
Il est même recommandé et utilisé dans le code passe
Felipe Lima

1
avec Oui, vous ne répondez pas Oui à "Y a-t-il d'autres mises en garde?" ? ;)
Caspar Kleijne

2
@Caspar Kleijne: J'ai expliqué le Oui avec le reste de la phrase.
Gumbo

1
Casper, Gumbo répondait en fait aux deux questions posées: "Est-ce complètement compatible avec tous les navigateurs? Y a-t-il d'autres mises en garde?" Oui est la réponse à la première question.
Darren Griffith

4

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 .


1

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.


vote négatif pour ne pas indiquer où le supplément: est utile. Partout où j'ai accidentellement laissé le ":" a rompu le lien
vol

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.