Hi lzr0,

Yes - any path previously using HTTP needs to be HTTPS now. You do this by hand or with an editor.

Use relative which you can, but the absolute paths need to use HTTPS.

In the future try and use relative paths for images, CSS files etc. This means if you ever need to change anything such as https, www to non-www or even your changing your domain name, these aspects of your site will just continue to work.

Mack.

I learned recently that you can leave off the protocol, and it will automatically match the protocol of the page the viewer is seeing.

Meaning:

<link rel="stylesheet" href="//www.example.com/styles.css">

If they load from HTTP then the CSS will use HTTP; if they use HTTPS then the CSS will use HTTPS.

I'm not sure if it affects speed, but if it does then it's minimal.

Much simplier to just use relative paths for local files (as mentioned a couple times above.)

From the OP:

(for example, sub-domains refer to css file in root directory with full url pass).

A relative URL doesn't work between domains.

@not2easy I don't see anyone recommending relative paths between domains.

use relative paths for local files

Switching to SSL

BTW - SSL is no longer used. It was replaced with TLS by the Internet Engineering Task Force [en.wikipedia.org]


- - -

Do I need to manually change all these urls to https on all my pages one at a time, or there is a smarter way (say, through htaccess)?

Just thinking, this might work in your .htaccess:

RewriteEngine on

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} .(css|js|jpg|jpeg|png|gif)$
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Depending on your setup, you might be able to just leave the second RewriteCond out and force everything to be HTTPS.

@csdude55 - file paths using HTTP will still display an error in the browser.

The paths need to physically be changed.

this might work

I think the problem is that some browsers simply won't send in the request in the first place. If no request is received, no redirect can be sent.

between domains

This is the rare case where host is what matters, not domain. The locations blog.example.com/ and assets.example.com/ may be the same domain, but they're different hosts--heck, they might even live on different servers--and as such can't be reached by relative links from one to another.

Can you use // with a hostname, though? I thought it was a subcategory of relative link: “match the hostname and also the protocol”.

@csdude55 - file paths using HTTP will still display an error in the browser.

What if he eliminated the second RewriteCond, then, and just forced all pages to HTTPS? That might be an immediate fix that gives him time to change all of his pages at a more leisurely pace.

I think the problem is that some browsers simply won't send in the request in the first place. If no request is received, no redirect can be sent.

Do you mean that using that HTACCESS code could make the browser not load his CSS at all?

Can you use // with a hostname, though? I thought it was a subcategory of relative link: “match the hostname and also the protocol”.

I saw that Google Adsense, Analytics, jQuery, and Cloudflare uses it, presumably so that you can use it on HTTP or HTTPS pages without incident. I changed my links to // and didn't see any differences in load time, and haven't seen any errors in any of the browsers I'm using. So I think it would be safe for him to change, and then never have to worry about it again.

>>Do you mean that using that HTACCESS code could make the browser not load his CSS at all?

if the actual web page has recources (such as images, css, js - whatever) that are not secure in the code (eg the html of the page) it is possible the browser (now or in the future) will simply not request them.
therefore the redirect is irrelevant as the resource will never have been requested.

I see... I've had that experience with 3rd party RSS files, so it makes sense.

My suggestion to the OP, then, would be to use the HTACCESS, but consider it a very temporary band-aid. Then just remove the http: from them and just use // instead.

Thank you all

@csdude55

RewriteEngine on

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} .(css|js|jpg|jpeg|png|gif)$
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Many thanks- will try. I was kind of hoping to avoid editing code on all pages. By the way, images seem to be loading even with non-https links.

[edited by: phranque at 1:29 pm (utc) on Dec 4, 2018]
[edit reason] unlinked url [/edit]

>> I was kind of hoping to avoid editing code on all pages

editing the code on all the pages is your best solution, most text editors have some kind of search and replace functionality, it shouldn't take long even for 100s of pages.

While you're working on it, if you have the option then you might want to change all of your links to a variable, then put that variable in a header or variable file that you include on every page.

Example, in PHP:

// in variables.php or header.php
<?php
$home = 'https://www.example.com';
?>

// at the top of every page, assuming it's in PHP
<?php
include '/path/to/variables.php';

echo <<<EOF
<a href='$home/page.php'>Click</a>
EOF;
?>

I do this, and have the majority of my variables in the variables.php file. This way, if I need to change anything on the site, I usually just have to change that one page to update everything.

@lzr0 - again, do *not* use that code csdude55 posted. If you still have HTTP paths in your markup, browsers will display errors and likely frighten away visitors.

As topr8 says, you *must* edit all file paths use HTTPS or use relative paths where possible.

Are you sure about that, keyplyr? topr8 said:

it is possible the browser (now or in the future) will simply not request them.

That's a lot less definite than your statement that browsers will display errors.

I haven't tested it, so I don't know. Are ALL browsers going to throw an error, or is that only an issue for some obsure or older browsers? The answer may be relevant to the OP.

I haven't tested it, so I don't know

So that's the problem. You are recommending code to members that you have not tested, nor do you have an understanding of how major browsers negotiate protocol for secure documents.

when i said:

editing the code on all the pages is your best solution

I was just being British and polite and understated ... perhaps i should have said:

editing the code on all the pages is your ONLY solution

of course check for yourself what happens in a modern browser!

but you only really have to consider this: it doesn't matter if you like it or not, currently google dominates the internet, either via search or the chrome browser... they have catagorically stated that https is the way to go ... without doubt you will suffer if your pages are not https ... so make sure your pages are https and ALL resources in your pages are also https

using redirects is NOT an option in this case, do not take what you think is a shortcut solution, you have to change your code (on the page)

no-one is infallible but in my experience keyplyr is very strong in this area (and others), it makes sense to strongly consider his viewpoint!

Thank you all, once again.
Following majority opinion, I am going to update all pages. I would still need to add 301 redirect in htaccess.

- Generic Steps to Switch from HTTP to HTTPS -
(Reposted from earlier discussions)
• Read all info at your host concerning certificates & switching to HTTPS and when applicable, follow those instructions.

• Install security certificate.

• Have your host enable HTTPS (if needed.) This will enable access from both HTTP & HTTPS allowing normal access while you test.

• Go through site, page by page & make sure all file paths are relative (no protocol.) Test by accessing site using HTTPS and look for any browser alerts.

• Install 301 code in .htaccess file

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Note: your server may require different code

• Go through site again, page by page, and test. Any remote absolute links will need to be HTTPS including those found in scripts & pluggins. If you publish Adsence or other advertising, links in these scripts need to be HTTPS also (or just remove the protocol altogether.)

• Update sitemap.xml (if applicable) and submit to appropriate agencies (Google, Bing, Yandex, etc)

• In Google Search Council create a new site using HTTPS (do not use the Change of Address form.) It will take a few days to start populating information. This is normal & traffic to old site (HTTP) will drop off accordingly.

• Bing Webmaster Tools, Yandex & others should update automatically once they crawl your new pages. Updating/re-submitting sitemap.xml should speed up this process.

- - -

@keyplyr

Thank you very much for detailed instructions. Hostgator was nice enough to provide SSL to their hosting customers, so my site already opens from both http and https, I just need to fix the links and then redirect.

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Will this code redirect sub-domains as well (i.e. from

http://subdomain.mysite.com

to

https://subdomain.mysite.com

) or I need to add a separate line for each sub-domain?

Read all info at your host concerning certificates & switching to HTTPS and when applicable, follow those instructions

You will likely need to do everything for each subdomain, including a cert & the redirect code... but your host will be the one to ask.

https://%{HTTP_HOST}

Don’t do this. Requests for
http://example.com
will then be sent to
https://example.com
while requests for
http://www.example.com
are sent to
https://www.example.com
and then half of those requests will have to be redirected all over again. (Where is your existing canonicalization redirect? I don’t see it.)

The optimal wording of the rule will depend on exactly how many subdomains you’ve got, and possibly on whether your preferred “base” domain is with or without www.

That's assuming you don't serve different content at example.com and www.example.com. This is theoretically possible, but I have never personally met a site that did so.

@lucy24

Actually, I found my webhost recommends a different script:

# Replace 'www.example.com' with your domain name (as it appears on your SSL certificate)
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

I will need to check with them how is this script going to handle subdomains.

Go through site, page by page & make sure all file paths are relative

Once 301 is set, is there any advantage of putting relative links vs. full pass to https?

Relative links are almost always preferable. After all, full paths are what got you into this fix in the first place.

Do you currently have a canonicalization redirect at all? One that accepts either "example.com" OR "www.example.com" but not both. Or do you leave it up to your host? I know mine's got a clickbox where you can express a preference, but I disabled it early-on in favor of keeping it under my own control.

@lucy24

My problem was related to sub-domains addressing some files in the main domain, but [unless I am missing something] there is no way of making a relative pass from subdomains to root anyway. Otherwise, relative links of course make it easier testing both versions, but it also makes job easier for scrapers. I was just wondering if there are other reasons of relative url when going to https that I was not aware of.

but it also makes job easier for scrapers

Scrapers know how to deal with URLs relatives or absolutes. Don't "worry" for them. (ironical)