Adding links: can I use //domain (double slash) for both https:// and http://

Question

We are moving to https soon. I understand that it is smart to use //domain.com links and images src references.

• Does the browser then first try https? and if not found http?
• Is this supported by all browsers?

In the end should all the links on the site use //domain.com (with double slash)?

And does Google understand (and follow) //domain.com links?

Solution 1

Browsers do not try one protocol and then fall back to the other. The browser will use which ever protocol it is linked to. If that protocol isn't supported, the user will get an error.

If you want to force users to use one protocol, you can redirect from one to the other. For example, to force secure connection on your site use the following rewrite rule in your .htaccess. It will issue 301 redirects from http://example.com/page.html to https://example.com/page.html (source)

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]

It sounds like you want to allow users to use either and to have them stay on the one they choose. That is fine. There are multilple ways that you can format relative links on your site to support that. Using // is not the one that I would recommend.

If your user is on https://example.com/foo.html and you want them to go to https://example.com/bar.html, then any of the following href will work in the a tag:

• Full URL -- https://example.com/bar.html -- If the user is on the http site, it will bring them over to the https site.
• Protocol relative -- //example.com/bar.html -- The user will be directed to either https://example.com/bar.html or http://example.com/bar.html depending on which protocol they are currently using.
• Site relative -- /bar.html -- Both the protocol and the domain name remain the same, the whole path in the URL changes.
• Directory relative -- bar.html -- Replaces the document portion in the URL (everything after the last slash)

I recommend using site relative links that start with a single slash most of the time when linking to other things on your site. Like the protocol relative URLs, users will use the same http or https that they currently use. It is a lot less typing (and makes pages smaller) than using full urls or protocol relative URLs.

Directory relative URLs can also work but they can be tricky in a few cases:

• Linking from example.com/bar/foo.html to example.com/bar/ is tricky. The directory relative URL for that is ./ where the . means 'current directory. The site relative URL is just /bar/.
• Linking to the directory up uses .. notation. So to link from example.com/bar/foo.html to example.com/baz.html the link would be ../baz.html The server relative link would be just /baz.html.

You may want to use directory relative links to link to other documents that are known to be in the current directory and use site relative links to link to JS, CSS, and images that are usually at or near the root of the site.

Protocol relative directives are most useful for linking to other sites where you want to preserve the protocol. I use that most often for third party JavaScript or images. If they are not fetched as secure, when my user is secure, the user gets a warning. If my user isn't secure, then it may make my site slower to to fetch resources from other sites securely. For example, if you were using currency data from my currency conversion site, you might link to its third party JavaScript like <script src="//coinmill.com/frame.js"></script>

All modern browsers and search engines support all of these types of links.

Solution 2

// basically means that the a resource will be requested in the same protocol, thus if someone is browsing httpS://yourwebsite.com, and you include a stylesheet like //yourwebsite.com/style.css, it will load httpS://yourwebsie.com/style.css.

If you request resources from http when the page is https, the browser may give an error.

To answer your questions:

Does the browser then first try https? and if not found http?

No, if the // isn't found it will just return the sufficient HTTP status code.

Is this supported by all browsers?

As far as I know all browsers support this, but don't take my word for it...

Solution 3

At https://developers.google.com/speed/libraries/devguide Google recommends using <script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script> to link to jQuery, for example. Google hosts the jQuery libraries at both http and https. The browser will use the same protocol as was used to reach your site to fetch the included JavaScript code. It will not try one and then the other! You don't want the site to suddenly become non-secure because a resource can only be found via http! This has the advantage of not using a secure connection just for JS if your site is being accessed via http, and not prompting a warning that some resources are not secure if your site is being accessed via https.

It is probably better to use this method (//domain.tld/) for external resources if your site switches from http to https (e.g. user logged in/not logged in). If you always use http you don't need it, if you always use https you don't need it as you can just hard-code the same protocol into your URLs, however, it will do no harm.

You don't need it for internal resources if you are using relative URLs as the browser will stick with the same protocol.

Comments

[Admin]

See also this blog post: paulirish.com/2010/the-protocol-relative-url

[Stephen Ostermiller]

I often see that webmasters don't know about it and link to index.html instead.

[Lightness Races in Orbit]

Well I'd posit that that says more about the training of those web programmers and less about the "trickiness" of some very basic and simple relative URLs. :) It's also likely that such programmers have little to no appreciation — at the present stage of their career — of abstracting away the DirectoryIndex and letting the webserver handle it, rather than hardcoding references to index.html itself. Surely this is a big component of the stated problem.

[snh_nl]

Super. And does Google (for seo) understand it and follow it you think?

[cnayak]

@snh_nl Yes, Google is compatible with this as far as I'm aware.

[dhaupin]

In addition to that HTACCESS - You can also force SSL client side using 307 internal redirect by setting a 180+ day cache time on a HSTS header. This has a bonus of further distinguishing or "future proofing" reltive // urls as well as helping prevent XSS or MITM. Also note: ./ ups are not good to use on some platforms that can dynamic route. Opencart comes to mind - there can be multiple cats between same product meaning a ./ would be highly inaccurate. Unless its absolute folder paths in something like CSS, dont use it.