Advantages of using // instead of

//Default protocol

/The use of the default protocol means that the protocol for resource access is consistent with the current page. If the current page is http, use the http protocol to access it. If If it is https, use https protocol to access. In this way, there is no need to change the code whether it is http or upgraded to https. Now many CDN resources are referenced in this way. It is generally used in internal links because the protocol header of external links is uncertain.

With the massive hijacking by domestic operators, etc., people insert a large number of vulgar advertisements when visiting the website, reducing the user experience, so the major search engines hope that everyone will try their best to convert the site to https method

//What does it mean?

//is the way to write the default protocol, for example

//jb51.net/css/

The default protocol is used by default Current protocol

When the current page is HTTP, it is equivalent to

http://jb51.net/css/

When the current page is HTTPS, Equivalent

https://jb51.net/css/

What are the conditions and benefits of using // instead of http://?

The current page and the target resource support both HTTP and HTTPS and are being upgraded from http to https

The advantage is that the request protocol of the resource can be adaptively selected according to the way the user opens the page. ,

For the content of https pages, the browser will organize non-https content by default, which can avoid this situation

// Disadvantages

Open directly When debugging local files, the protocol used is the file protocol (file://)

At this time, the protocol will become file://jb51.net/css/ which obviously does not exist

Be consistent with the current website protocol, quickly release a version that matches your current protocol, and reduce the deployment cost of SSL or other protocol versions. Developers do not need to worry about what protocols are provided by the server cloud. They only need to use the // symbol to represent the most suitable match. This is in line with the thinking of nodeJS.

The advantages are as follows:

Because many websites have upgraded http to https, this can prevent our URL from being hijacked. In order to prevent me from making mistakes during the conversion process in the early stage We do not have a forced jump, that is, when users access http or https, they can access it normally, but the js, pictures, links, etc. inside cannot use https or http. So what is the solution? The solution is to use // , don't bring http: and https and that's it.

//This way of writing automatically adds the protocol according to the protocol you requested. For example: your website uses the http protocol, so what you actually access is http://xxxx. If your website uses the https protocol, then the requested address will become https://xxxx. You know, if you write http://xxx. Then if your website is https online, a security warning may be reported, and some browsers may not even be able to load the page normally. If you write https directly, you must know that local development is http...

The following content is some classic replies from Zhihu

The benefits are many people Answered. This benefit is certainly most felt when upgrading to https. I'm just adding a reason why predecessors didn't write this way. Of course, there are indeed many front-ends who don't know this way of writing. However, even if you knew it, you probably wouldn't be able to write it like this. Because many earlier versions of UC Browser do not support this writing method, //a.b/ will be directly understood as /a.b/, that is, if you write //example in the page http://example.com -The address of cdn.net/static-file, UC actually accesses http://example.com/example-cdn.net/static-file. Everyone knows UC’s past market share. So...

At first glance, it seems that you have not done "full-site HTTPS upgrade". When I upgraded the entire site to HTTPS, I really wanted to kill the person who wrote http://. Especially the links in the database and the URLs spliced ​​together in JS. During this period, various regular rules were used and manual verification was required. However, there were too many programmers writing http://, so they had no choice but to give up. Some people also asked the reason in the comments. The reason is that if you write // in full, I don't need to modify the data and source code in the database. I can just upgrade https. You may say that https transformation rarely happens. By coincidence, I encountered https transformation at both Tencent and Alibaba. And when I was at Alibaba, I was responsible for the front-end code transformation of the entire 1688 website (individual departments modified themselves) ( Not just HTML, but also CSS, JS, Velocity templates, etc. It’s simply a dirty job, why would I take this job?) Guess how many times I scolded the person who wrote http://? Some front-ends also write http directly in JS. Will you die if you continue to use the protocol of the current page?

Some front-ends only accept http:// and https:// but not // when using regular expressions to judge URLs. This is really a lack of common sense. Too many programmers, too retarded. Or maybe it’s just that they haven’t heard of HTTPS. If you still don’t understand, let me ask you a few questions: If you use http://, then you default to the current page using the http protocol. Why do you, a front-end, decide the protocol of the current page? Don’t you know that http links will report errors in https pages? You should continue to use the protocol of the current page, so you have to write // If you use https://, it is the same problem. How do you know whether there will be an https:// in three years? Will you change everything by then? into https://? Don't make any assumptions that are obviously wrong! You have no idea what protocol the current page will be opened with! So you have to use // Ah! There are many similar wrong assumptions. For example, many Chinese programmers believe that phone numbers only contain numbers and brackets, not letters. Is it really?

Some people say that global replacement is not enough? For example, suppose Taobao wants to upgrade https, so you replace all http:// with //. The first bug: you replace with , but at that time http://tmail.com did not support https, so you replaced the domain name within a certain range, http://(taobao|taobao2|taobao3).com //$1.com second bug: Some JS is written like this url = "http://" + location.hostname + '/' + path, and some JS is written like this /^http:\/\ //.test(input). You said that there is no way to use regular expressions. Search http globally in all JS and then review it manually. Do you know how many JS files there are on Taobao... And these files have been cached for ten years... Even if you change them, they may not be updated. And once you make a mistake and affect users’ orders, can you afford to pay Jack Ma’s loss of 100 million? The third bug: Some data is not in the code at all, but in the database. For example, the value of user.image starts with http. So you write user.image as user.image.replace('http://', ​​'//') or you directly change the data in the database (when the amount of data is large, this is basically impossible). Four bugs: You forgot to change the domain name in nginx and crossdomain. The fifth bug: You forgot to change the base_url in the configuration system. The sixth bug: Your https page embeds an external http iframe... Just cry. , this is difficult to solve. If you are lucky, just change it to // (external support for https is enough). If you are not lucky, you will have to change the page logic. The Nth bug... HTTPS upgrade is a dirty job. If you say it's easy, you'll do it. Once you start doing it, you'll know how many things are involved. The best solution is to make the protocol easy to change, such as following the current page, or using variables. Anyway, it is definitely not good to hardcode http://. When some programmers write code, they clearly know that HTTPS is available but do not make it compatible. They think, "I will leave this company after two years, and HTTPS will have at least three more years." Then they write garbage code.

More and more developers use // instead of http:// when linking files, that is, < a href="http://jb51.net ... Generally written as < a href = " //http://jb51.net..., what is the difference between this and the traditional http?

Originally your website was http, and all the srcs started with http. I thought it was hijacked by shit operators and stuffed a lot of content inappropriate for children/and pure advertising into your page. Sometimes, someone tells you that replacing https can improve this problem. Then you will know what a wise decision it was that the previous src and ajax were written as // instead of http://. . .

Zhulang CMS official

With the emergence of more and more open source and cloud platforms and the widespread introduction of SSL protocols (such as Zhulang CMS has fully enabled SSL Protocol support), people have to face the choice and identification of http protocol when developing. As we all know, too many SSL references may cause inefficiency of ordinary sites, but we cannot redesign a pure SSL version for this reason. As shown in open source libraries, most platforms provide both SSL and non-SSL versions. Such as these two libraries: https://code.z01.com/js/jquery-3.2.1.slim.min.jshttp://code.z01.com/js/jquery-3.2.1.slim.min. The reference effect of js is consistent. So developers directly use the "//URL/File" method to replace the previous protocol so that it can be automatically recognized. That is, whether it is the SSL protocol or the ordinary http protocol, it is left to the browser to automatically identify and automatically match the current site, thereby achieving the best secure request and the most efficient loading method. In short, this is a development method and development thinking, and cloud computing web and mobile development are growing day by day.

Related recommendations:

thinkPHP Development (http://w2ks.com)

The above is the detailed content of Advantages of using // instead of. For more information, please follow other related articles on the PHP Chinese website!