Avantages d'utiliser // au lieu de

//Protocole par défaut

/L'utilisation du protocole par défaut signifie que le protocole d'accès aux ressources est cohérent avec la page actuelle. Si la page actuelle est http, utilisez le http. protocole pour y accéder. S'il s'agit de https, utilisez le protocole https pour y accéder. De cette façon, il n'est pas nécessaire de modifier le code, qu'il soit http ou mis à niveau vers https. Désormais, de nombreuses ressources CDN sont référencées de cette manière. Il est généralement utilisé dans les liens internes car l’entête protocolaire des liens externes est incertain.

Avec le détournement massif par les opérateurs nationaux, etc., les gens insèrent un grand nombre de publicités vulgaires lorsqu'ils visitent des sites Web, réduisant ainsi l'expérience utilisateur. Par conséquent, les principaux moteurs de recherche espèrent que chacun fera de son mieux pour convertir le site. à la méthode https

//Qu'est-ce que ça veut dire ?

// est la manière d'écrire le protocole par défaut, par exemple,

//jb51.net/css/

Le protocole par défaut utilise le protocole actuel par défaut

La page actuelle est Lorsque HTTP, elle équivaut à

http://jb51.net/css/

Lorsque la page actuelle est HTTPS, elle équivaut à

https://jb51.net/css/

. Utilisez plutôt //. Quelles sont les conditions et les avantages de http:// ?

La page actuelle et la ressource cible prennent en charge à la fois HTTP et HTTPS et sont en cours de mise à niveau de http vers https

L'avantage est que le protocole de requête de la ressource peut être sélectionné de manière adaptative en fonction à la manière dont l'utilisateur ouvre la page. ,

Pour le contenu des pages https, le navigateur organisera par défaut le contenu non-https, ce qui peut éviter cette situation

// Inconvénients

Ouvrir directement Lors du débogage des fichiers locaux, le protocole utilisé est le protocole de fichier (file://)

A ce moment, le protocole deviendra file://jb51. net/css/ qui n'existe évidemment pas

Soyez cohérent avec le protocole actuel du site Web, publiez rapidement une version qui correspond à votre protocole actuel et réduisez le coût de déploiement de SSL ou d'autres versions de protocole. Les développeurs n'ont pas à se soucier des protocoles fournis par le cloud du serveur. Ils n'ont qu'à utiliser le symbole // pour représenter la correspondance la plus appropriée. Cela est conforme à la pensée de nodeJS.

Les avantages sont les suivants :

Parce que de nombreux sites Web ont mis à niveau http vers https, ce qui peut empêcher notre URL d'être piratée afin de faire une erreur lors du piratage. processus de conversion au début, nous n'avons pas de saut forcé, c'est-à-dire que lorsque les utilisateurs accèdent à http ou https, ils peuvent y accéder normalement, mais les js, les images, les liens, etc. à l'intérieur ne peuvent pas utiliser https ou http. est la solution ? La solution est d'utiliser // , n'apportez pas http: et https, c'est tout.

//Cette façon d'écrire ajoute automatiquement un protocole basé sur le protocole que vous avez demandé. Par exemple : votre site Web utilise le protocole http, donc ce à quoi vous accédez réellement est http://xxxx. Si votre site Web utilise le protocole https, alors l'adresse demandée deviendra https://xxxx. Vous savez, si vous écrivez http : //xxx. Ensuite, si votre site Web est en ligne https, un avertissement de sécurité peut être signalé et certains navigateurs peuvent même ne pas être en mesure de charger la page normalement. Si vous écrivez directement https, vous devez savoir que le développement local est http...

Le contenu suivant est quelques réponses classiques de Zhihu

Les avantages sont de nombreuses personnes répondues . Cet avantage se fait certainement plus sentir lors de la mise à niveau vers https. J'ajoute simplement une raison pour laquelle les prédécesseurs n'écrivaient pas de cette façon. Bien sûr, il existe effectivement de nombreux front-ends qui ne connaissent pas cette façon d'écrire. Cependant, même si vous le saviez, vous ne seriez probablement pas capable de l’écrire ainsi. Étant donné que de nombreuses versions antérieures d'UC Browser ne prennent pas en charge cette méthode d'écriture, //a.b/ sera directement compris comme /a.b/, c'est-à-dire que si vous écrivez //example dans la page http://example.com -. L'adresse cdn.net/static-file, UC accède en fait à http://example.com/example-cdn.net/static-file. Tout le monde connaît la part de marché passée des communications unifiées. Alors...

À première vue, il semble que vous n'ayez pas effectué de "mise à niveau HTTPS à l'échelle du site". Lorsque j'ai mis à niveau l'intégralité du site vers HTTPS, je voulais vraiment tuer la personne qui a écrit http://. Surtout les liens dans la base de données et les URL assemblées dans JS. Durant cette période, diverses règles régulières ont été utilisées et une vérification manuelle était requise. Cependant, il y avait trop de programmeurs qui écrivaient http://, ils n'avaient donc d'autre choix que d'abandonner. Certaines personnes ont également demandé la raison dans les commentaires. La raison est que si vous écrivez // en entier, je n'ai pas besoin de modifier les données et le code source de la base de données, je peux simplement mettre à niveau https. Vous pouvez dire que la transformation https se produit rarement. Par coïncidence, j'ai rencontré la transformation https chez Tencent et Alibaba. Et lorsque j'étais chez Alibaba, j'étais responsable de la transformation du code front-end de l'ensemble du site Web 1688 (les départements individuels se modifiaient eux-mêmes). (Pas seulement HTML, mais aussi CSS, JS, modèles Velocity, etc. C'est juste du sale boulot, pourquoi diable ai-je accepté ce travail ?) Devinez combien de fois j'ai grondé la personne qui a écrit http:// ? Certains frontaux écrivent également http directement dans JS. Mourrez-vous si vous continuez à utiliser le protocole de la page actuelle ?

Certains frontaux n'acceptent en fait que http:// et https:// mais pas // lorsqu'ils utilisent des expressions régulières pour juger les URL. C'est vraiment un manque de bon sens. Trop de programmeurs, trop attardés. Ou peut-être est-ce simplement qu’ils n’ont pas entendu parler du HTTPS. Si vous ne comprenez toujours pas, laissez-moi vous poser quelques questions : Si vous utilisez http://, vous accédez par défaut à la page actuelle en utilisant le protocole http. Pourquoi, en tant que frontal, décidez-vous du protocole du. la page actuelle ? Ne savez-vous pas que les liens http signaleront les erreurs dans les pages https ? Vous devez continuer à utiliser le protocole de la page actuelle, vous devez donc écrire //Si vous utilisez https://, c'est le même problème. Comment savoir s'il y aura un https:// dans trois ans ? Allez-vous tout changer d'ici là ? Ne faites aucune hypothèse qui serait manifestement fausse ! Vous n'avez aucune idée avec quel protocole la page actuelle sera ouverte ! Il faut donc utiliser // Ah ! Il existe de nombreuses hypothèses erronées similaires. Par exemple, de nombreux programmeurs chinois pensent que les numéros de téléphone ne contiennent que des chiffres et des crochets, pas des lettres. Est-ce vraiment le cas ?

Quelqu'un a dit que le remplacement global n'était pas la fin ? Par exemple, supposons que Taobao souhaite mettre à niveau https et que vous remplacez tous les http:// par //Le premier bug : vous remplacez par , mais à cette époque, http://tmail.com ne prenait pas en charge https, vous avez donc remplacé le nom de domaine dans une certaine plage, http://(taobao|taobao2|taobao3).com // Deuxième bug de $1.com : certains JS sont écrits comme ceci url = "http://" + location.hostname + '/' + chemin, et certains JS sont écrits comme ceci /^http:/// .test(input) . Vous avez dit que vous ne pouviez pas utiliser de règles régulières pour cela. Recherchez http globalement dans tous les JS, puis examinez-le manuellement. Savez-vous combien de fichiers JS il y a sur Taobao... Et ces fichiers sont mis en cache depuis dix ans... Même si vous les modifiez, ils risquent de ne pas être mis à jour. Et une fois que vous faites une erreur et affectez les commandes des utilisateurs, pouvez-vous vous permettre de payer la perte de 100 millions de Jack Ma ? Le troisième bug : certaines données ne sont pas du tout dans le code, mais dans la base de données. Par exemple, la valeur de user.image commence par http. Vous écrivez donc user.image sous la forme user.image.replace('http://', ​​​​'//') ou vous modifiez directement les données dans la base de données (lorsque la quantité de données est importante, c'est fondamentalement impossible) . Quatre bugs : Vous avez oublié de changer le nom de domaine dans nginx et crossdomain. Le cinquième bug : Vous avez oublié de changer le base_url dans le système de configuration. Le sixième bug : Votre page https embarque une iframe http externe... Pleurez. c'est difficile à résoudre. Si vous avez de la chance, changez-le simplement en // (un support externe pour https suffit. Si vous n'avez pas de chance, vous devrez changer la logique de la page). Le nième bug... La mise à niveau HTTPS est un sale boulot. Si vous dites que c'est facile, vous le ferez. Une fois que vous aurez commencé à le faire, vous saurez combien de choses sont impliquées. La meilleure solution est de rendre le protocole facile à modifier, par exemple en suivant la page actuelle ou en utilisant des variables. Quoi qu'il en soit, il n'est certainement pas bon de coder en dur http://. Lorsque certains programmeurs écrivent du code, ils savent clairement que HTTPS est disponible mais ne le rendent pas compatible. Ils pensent : « Je quitterai cette entreprise après deux ans, et HTTPS aura encore au moins trois ans. » Ensuite, ils écrivent du code inutile.

De plus en plus de développeurs utilisent // au lieu de http:// lors de la liaison de fichiers, comme

À l'origine, votre site Web était http, et tous les srcs commençaient par http. Je pensais qu'il avait été détourné par des opérateurs de merde et avait rempli votre page de beaucoup de contenu inapproprié pour les enfants/et de pure publicité. Parfois, quelqu'un le dit. vous dire que le remplacement de https peut améliorer ce problème. Vous saurez alors à quel point ce fut une sage décision que les précédents src et ajax aient été écrits en // au lieu de http://. . .

Zhulang CMS Officiel

Avec l'émergence de plus en plus de plates-formes open source et cloud et l'introduction généralisée des protocoles SSL (tels que Zhulang CMS a entièrement activé le protocole SSL support), les utilisateurs doivent faire face au choix et à l'identification du protocole http lors du développement. Comme nous le savons tous, trop de références SSL peuvent entraîner une inefficacité des sites ordinaires, mais nous ne pouvons pas repenser une version purement SSL pour cette raison. Comme le montrent les bibliothèques open source, la plupart des plates-formes proposent des versions SSL et non SSL. Comme ces deux bibliothèques : https://code.z01.com/js/jquery-3.2.1.slim.min.jshttp://code.z01.com/js/jquery-3.2.1.slim.min. L'effet de référence de js est cohérent. Les développeurs utilisent donc directement la méthode "//URL/Fichier" pour remplacer le protocole précédent afin qu'il soit automatiquement reconnu. Autrement dit, qu'il s'agisse du protocole SSL ou du protocole HTTP ordinaire, il appartient au navigateur d'identifier et de faire correspondre automatiquement le site actuel, obtenant ainsi la meilleure requête sécurisée et la méthode de chargement la plus efficace. En bref, il s'agit d'une méthode de développement et d'une réflexion sur le développement, et le développement Web et mobile du cloud computing se développe de jour en jour.

Recommandations associées :

développement thinkPHP (http://w2ks.com)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!