Question Est-il valide de remplacer http: // par // dans un


Réponses:


Une URL relative sans schéma (http: ou https :) est valide, par RFC 3986: "Uniform Resource Identifier (URI): Syntaxe générique", Section 4.2. Si un client s'y oppose, c'est la faute du client car il ne respecte pas la syntaxe d'URI spécifiée dans la RFC.

Votre exemple est valide et devrait fonctionner. J'ai moi-même utilisé cette méthode d'URL relative sur des sites à fort trafic et je n'ai reçu aucune plainte. Nous testons également nos sites dans Firefox, Safari, IE6, IE7 et Opera. Ces navigateurs comprennent tous ce format d'URL.


374
2018-02-15 00:39



Il est garanti de fonctionner dans tous les navigateurs classiques (je ne prends pas en compte les navigateurs dont la part de marché est inférieure à 0,05%). Heck, cela fonctionne dans Internet Explorer 3.0.

RFC 3986 définit un URI composé des parties suivantes:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

Lors de la définition des URI relatifs (Section 5.2), vous pouvez omettre une de ces sections, en commençant toujours par la gauche. En pseudo-code, cela ressemble à ceci:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

L'URI que vous décrivez est un URI relatif sans schéma.


147
2018-06-04 15:50



Y a-t-il des cas où cela ne fonctionne pas?

Si la page parente a été chargée depuis file://, alors ça ne marche probablement pas (ça va essayer d'avoir file://cdn.example.com/js_file.js, que bien sûr vous pourriez fournir localement aussi bien).


75
2017-10-19 08:27



Beaucoup de gens appellent cela une URL Relative au Protocole.

Il provoque un double téléchargement de fichiers CSS dans IE 7 et 8.


40
2018-06-04 15:49



Ici, je duplique la réponse dans Les fonctionnalités cachées de HTML:

Utilisation d'un absolu indépendant du protocole   chemin:

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

Si le navigateur affiche une page dans   SSL via HTTPS, alors il va demander   cet actif avec le protocole https,   sinon, il le demandera avec HTTP.

Cela empêche ce terrible "Cette page   Contient à la fois sécurisé et non sécurisé   Articles "message d'erreur dans IE, en gardant   toutes vos demandes d'actifs dans le   même protocole.

Mise en garde: Utilisé sur un <link> ou   @import pour une feuille de style, IE7 et IE8    télécharger le fichier deux fois. Tous les autres   les utilisations, cependant, sont très bien.


22
2018-02-15 02:02



Il est parfaitement valable d'abandonner le protocole. Les spécifications de l'URL sont très claires à ce sujet depuis des années et je n'ai pas encore trouvé de navigateur qui ne le comprenne pas. Je ne sais pas pourquoi cette technique n'est pas mieux connue. c'est la solution parfaite au problème épineux du franchissement des frontières HTTP / HTTPS. Plus ici: Transitions Http-https et URL relatives


16
2018-06-03 08:20



Y a-t-il des cas où cela ne fonctionne pas?

Juste pour lancer ceci dans le mix, 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 src="//cdn.example.com/js_file.js"est src="file://cdn.example.com/js_file.js", qui va casser puisque vous n'hébergez pas cette ressource localement.

Microsoft Internet Explorer semble être particulièrement sensible à cela, consultez 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>

METTRE À JOUR: HTML5Boilerplate utilise maintenant <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 au protocole, voir [ici] [3].


5
2018-04-13 08:17



Suite à la référence du gnud, le RFC 3986 section 5.2 dit:

Si le composant du schéma est défini, indiquant que la référence   commence par un nom de schéma, alors la référence est interprétée comme un   URI absolue et nous avons terminé. Sinon, le schéma de l'URI de référence   est hérité du composant du schéma de l'URI de base.

Alors // est correct :-)


3
2018-06-04 15:49



Oui, ceci est documenté dans RFC 3986, section 5.2:

(edit: Oups, ma référence RFC était obsolète).


2
2017-09-03 10:28