What are the benefits of using // instead of http:// (adaptive https)

//Default protocol

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

What does // mean?

// is the default protocol, for example

//jb51.net/css/

Default protocol uses the current protocol by default

When the current page is HTTP, it is equivalent to

http://jb51.net/css/

When the current page is HTTPS, the equivalent

https://jb51.net/css/

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

The current page and target resource support both HTTP and HTTPS. Upgrading from http to https

The advantage of this is that it can adaptively select the resource request protocol 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

// shortcoming

When you open a local file directly for debugging, the protocol used is the file protocol (file://)

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

Keep consistent with the protocol of the current website, 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 protocol the server cloud provides, they just need to use // symbols to represent the most suitable matches, which is consistent with the thinking of nodeJS.

The advantages are as follows:

Because many websites have upgraded http to https, this can prevent our website from being hijacked. In the early stage, in order to avoid errors during the conversion process, we did not force a jump. That is, when users access http or https, they can access it normally, but the js, pictures, links, etc. in it cannot use https or http. So what is the solution? The solution is to use //, without http: and https.

//This way of writing automatically adds the protocol based on the protocol you requested. For example: if your website is http protocol, then what you actually visit is http://xxxx. If your website is https protocol, then the requested address will become https://xxxx. You should know that if you write http://xxx. If your website is https online, then you may get a security warning, and some browsers may not even be able to load the page normally. If you write it directly as https, you should know that local development is http...

The following are some classic replies from Zhihu

Many people have answered the question about the benefits. Of course, this benefit can be felt most by upgrading https. I am just adding a reason why previous people didn't write it this way. Of course, there are indeed many front-end developers who don’t know how to write this. However, even if you know this, you probably won’t be able to write it this way. Because many earlier versions of UC Browser do not support this writing method, they will directly understand //ab/ as /ab/. That is to say, if you write the address //example-cdn.net/static-file in the http://example.com page, UC actually accesses http://example.com/example-cdn.net/static-file. Everyone knows UC's past market share. so……

I can tell at a glance that you haven’t done a “full site HTTPS upgrade”. When I upgraded the entire site to HTTPS, I really wanted to kill anyone who wrote http://. Especially the links in the database and the URLs spliced ​​together in JS. Various regular expressions were used during the process, and manual verification was also required. Unfortunately, there are too many programmers who write http://, so I have to give up. Someone asked the reason in the comments. The reason is that if you write all //, I don’t need to modify the data and source code in the database, I can directly upgrade https. You may say that https transformation rarely happens. Coincidentally, I encountered https transformation in both Tencent and Alibaba. When I was in Alibaba, I was responsible for the front-end code transformation of the entire 1688 website (individual departments transformed it on their own) (not just HTML, but also CSS, JS, Velocity templates, etc.! It was really dirty and tiring work, why the hell should I take this job?). Guess how many times I scolded the people who wrote http://? Some front-end developers even write http directly in JS. Will you die if you 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 stupid. Or maybe they just haven't heard of HTTPS. If you still don't understand, let me ask you a few questions: If you use http://, then you are assuming that the current page is using the http protocol. How can you, as a front-end developer, decide the protocol of the current page? Don’t you know that http links will report errors in https pages? You should use the protocol of the current page, so you have to write //. If you use https://, the same problem occurs. How do you know if there will be an https:// in three years? Will you change all of them to https:// then? Don't make any assumptions that are obviously wrong! You don't even know what protocol the current page will be opened with! So you have to use //! There are many similar wrong assumptions. For example, many Chinese programmers think that telephone numbers only contain numbers and brackets, not letters. Is this really the case?

Some people say that global replacement is enough? For example, suppose Taobao is going to upgrade to https, so you replace all http:// with //. The first bug: you replaced <a href="http://tmail.com"> with <a href="//tmail.com">, but http://tmail.com did not support https at that time, so you replaced the domain names within a certain range, http://(taobao|taobao2|taobao3).com with //$1.com. The 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 regular expressions cannot be used for this. Just search for http globally in all JS and then manually review it. Do you know how many JS files Taobao has? And these files are cached for ten years. Even if you change them, they may not be updated. And if you make a mistake and affect users' orders, can you afford to compensate Jack Ma for a 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). The fourth bug: 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). If you are unlucky, you have to change the page logic. The Nth bug... HTTPS upgrade is a dirty and tiring job. You say it's easy and you do it, but once you start, you will 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 a good idea to hardcode http://. Some programmers know that HTTPS exists but do not try to make it compatible when writing code, thinking "I will leave this company after two years, and HTTPS will still be around for at least three years", and then they write garbage code.

More and more developers use // instead of http:// when linking files. For example, < a href="http://jb51.net... is 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 src's started with http. You thought it was hijacked by a shitty operator, and your pages were filled with a lot of content that is not suitable for children and pure advertising. Someone told you that replacing https can improve this problem. At this time, you will know how wise it was to write // instead of http:// in the previous src and ajax. . .

Zhulang CMS Official

With the emergence of more and more open source and cloud platforms and the widespread introduction of the SSL protocol (for example, Zhulang CMS has fully enabled SSL protocol support), people have to face the selection and identification of the 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 purpose. As for open source libraries, general 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.js their reference effects are 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 it with the current site, so as to achieve the best security request and the most efficient loading method. In short, this is a development method and development thinking. Web and mobile development in cloud computing is growing stronger day by day.