: Adding links: can I use //domain (double slash) for both https:// and http:// We are moving to https soon. I understand that it is smart to use //domain.com links and images src references.

@Smith883

At 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.

Vote Up Vote Down

@BetL925

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 example.com/page.html to example.com/page.html (source)

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) %{SERVER_NAME}/ [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 example.com/foo.html and you want them to go to example.com/bar.html, then any of the following href will work in the a tag:


Full URL -- 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 example.com/bar.html or 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.

Vote Up Vote Down

@Megan663

// basically means that the a resource will be requested in the same protocol, thus if someone is browsing yourwebsite.com, and you include a stylesheet like //yourwebsite.com/style.css, it will load 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...

Vote Up Vote Down