Forcing all requests to HTTPS vs not forcing all requestsRedirecting one page to HTTPS, and all others back...
Is there a difference between historical fiction and creative non-fiction?
How to realize Poles and zeros at infinity??especially through transfer function?
How slow was the 6502 BASIC compared to Assembly
What is the next number in the sequence 21, 21, 23, 20, 5, 25, 31, 24, ...?
How to catch creatures that can predict the next few minutes?
Forcing all requests to HTTPS vs not forcing all requests
Injection from two strings to one string
Why didn't he give Sam the antidote?
Why didn't Trudy wear a breathing mask in Avatar?
What is the difference between 山道【さんどう】 and 山道【やまみち】?
The work of mathematicians outside their professional environment
Would Great Old Ones care about the Blood War?
What does it take to recreate microchips like 68000 and 6502 in their original process nodes nowadays?
In the Star Trek: TNG continuity is cloning illegal?
Why didn't Snape ask Dumbledore why he let "Moody" search his office?
How much money should I save in order to generate $1000/month for the rest of my life?
Transiting through Switzerland by coach with lots of cash
Is there any way to ward an area against Sending?
Why do English transliterations of Arabic names have so many Qs in them?
Which accidental continues through the bar?
AC/DC 100A clamp meter
"Es gefällt ihm." How to identify similar exceptions?
Characters in a conversation
Venn diagrams show + - = underneath
Forcing all requests to HTTPS vs not forcing all requests
Redirecting one page to HTTPS, and all others back to HTTP isn't working as expectedStandard Wordpress mod_rewrite rules interacting with one of my own rules are causing all requests for a certain page to be sent to the homepagePrevent Google Indexing SubDomainsBanning IPs through my htaccess doesn't work. Why?Wordpress, Apache and Nginx: permalinks and cacheHow do I setup redirect for multiple subdomains to different folders.htaccess doesn't redirect my pages from HTTP to HTTPSHow do I prevent a rewrite rule from executing for just one subdomain?Wordpress blog subdomain redirects to main site after switching to HTTPSHold my hand through my htaccess http to https redirects
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}
If this is a duplicate my apologies. I couldn't find anything that directly answered my question but it's possible I wasn't keying in on the correct search terms. So...
I'm not new to cleaning up mixed content errors after switching from http to https and I'm not new to working with the htaccess file but I am new to actually implementing the rules for http to https in the htaccess file. Obviously the goal is to switch all links that the search engines serve up from http to https but also to catch people who might have the site bookmarked at http or they happen to type in URLs manually because they have memorized them. I'm working with a WordPress site.
I read a lot of pages and thought I had a firm grasp on what to add to htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule. The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
So now I'm confused. Do I use both of these together or do I just need the second one to ensure everything goes to HTTPS?
And speaking of working with WordPress I also came across another article that said WordPress can be set to force all requests to HTTPS in the wp-config with...
define('FORCE_SSL_ADMIN', true);
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)? I would like guidance on this from those better in the know.
Also.. if there is a better condition/rule to use than those noted above let me know.
htaccess wordpress https mod-rewrite
add a comment
|
If this is a duplicate my apologies. I couldn't find anything that directly answered my question but it's possible I wasn't keying in on the correct search terms. So...
I'm not new to cleaning up mixed content errors after switching from http to https and I'm not new to working with the htaccess file but I am new to actually implementing the rules for http to https in the htaccess file. Obviously the goal is to switch all links that the search engines serve up from http to https but also to catch people who might have the site bookmarked at http or they happen to type in URLs manually because they have memorized them. I'm working with a WordPress site.
I read a lot of pages and thought I had a firm grasp on what to add to htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule. The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
So now I'm confused. Do I use both of these together or do I just need the second one to ensure everything goes to HTTPS?
And speaking of working with WordPress I also came across another article that said WordPress can be set to force all requests to HTTPS in the wp-config with...
define('FORCE_SSL_ADMIN', true);
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)? I would like guidance on this from those better in the know.
Also.. if there is a better condition/rule to use than those noted above let me know.
htaccess wordpress https mod-rewrite
Welcome to Webmasters!
– closetnoc
8 hours ago
add a comment
|
If this is a duplicate my apologies. I couldn't find anything that directly answered my question but it's possible I wasn't keying in on the correct search terms. So...
I'm not new to cleaning up mixed content errors after switching from http to https and I'm not new to working with the htaccess file but I am new to actually implementing the rules for http to https in the htaccess file. Obviously the goal is to switch all links that the search engines serve up from http to https but also to catch people who might have the site bookmarked at http or they happen to type in URLs manually because they have memorized them. I'm working with a WordPress site.
I read a lot of pages and thought I had a firm grasp on what to add to htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule. The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
So now I'm confused. Do I use both of these together or do I just need the second one to ensure everything goes to HTTPS?
And speaking of working with WordPress I also came across another article that said WordPress can be set to force all requests to HTTPS in the wp-config with...
define('FORCE_SSL_ADMIN', true);
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)? I would like guidance on this from those better in the know.
Also.. if there is a better condition/rule to use than those noted above let me know.
htaccess wordpress https mod-rewrite
If this is a duplicate my apologies. I couldn't find anything that directly answered my question but it's possible I wasn't keying in on the correct search terms. So...
I'm not new to cleaning up mixed content errors after switching from http to https and I'm not new to working with the htaccess file but I am new to actually implementing the rules for http to https in the htaccess file. Obviously the goal is to switch all links that the search engines serve up from http to https but also to catch people who might have the site bookmarked at http or they happen to type in URLs manually because they have memorized them. I'm working with a WordPress site.
I read a lot of pages and thought I had a firm grasp on what to add to htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule. The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
So now I'm confused. Do I use both of these together or do I just need the second one to ensure everything goes to HTTPS?
And speaking of working with WordPress I also came across another article that said WordPress can be set to force all requests to HTTPS in the wp-config with...
define('FORCE_SSL_ADMIN', true);
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)? I would like guidance on this from those better in the know.
Also.. if there is a better condition/rule to use than those noted above let me know.
htaccess wordpress https mod-rewrite
htaccess wordpress https mod-rewrite
edited 8 hours ago
MrWhite
32.8k3 gold badges35 silver badges69 bronze badges
32.8k3 gold badges35 silver badges69 bronze badges
asked 8 hours ago
KarenKaren
242 bronze badges
242 bronze badges
Welcome to Webmasters!
– closetnoc
8 hours ago
add a comment
|
Welcome to Webmasters!
– closetnoc
8 hours ago
Welcome to Webmasters!
– closetnoc
8 hours ago
Welcome to Webmasters!
– closetnoc
8 hours ago
add a comment
|
1 Answer
1
active
oldest
votes
I read a lot of pages and thought I had a firm grasp on what to add to
htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
Exactly what directives you need to use can depend on your server configuration. And to some extent personal preference (eg. whether you check the HTTPS
server variable or SERVER_PORT
).
These directives (checking against the HTTPS
server variable) are arguably the most common and should work when the SSL cert is installed directly on the application server (as opposed to a front-end proxy). This should be your goto HTTP to HTTPS redirect (but note the optimisation mentioned below*1).
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Yes, it would - providing they are the correct directives for your server config. The .htaccess
file is processed for all HTTP requests and that includes 1, 2 and 3.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule.
Without seeing the article in question; that is incorrect. When a user "types a URL manually", it's an HTTP request just like any other.
The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
These directives should only be used if the HTTPS connection (SSL cert) is being handled by a front-end proxy. If not, then you will most certainly get a redirect loop. The condition above checks the X-Forwarded-Proto
HTTP request header - which would ordinarily be set by a proxy server.
Likewise, if you used the first rule block that checks against the HTTPS
server variable on a server that uses a front-end proxy to handle the secure connection then you would also likely get a redirect loop.
Always test with 302 (temporary) redirects if in any doubt.
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)?
Yes, you should also change the wp-config. At the very least, it is a failsafe. But also, you don't want the situation when you are redirecting to HTTPS and WP is redirecting back to HTTP. (I'm not actually sure whether that would happen, but it is certainly true the other way round.)
if there is a better condition/rule to use than those noted above let me know.
As noted above, any one way is not necessarily "better". Its what works for you.
*1 However, there are small optimisations that can be made in the directive(s) you posted. For example, in your first rule, you use the less efficient regex ^(.*)$
. This regex traverses the entire string and captures the entire match in a backreference. This is unnecessary in the context it is being used. You aren't using any backreferences in the substitution and you simply need to trigger the rule for anything. In which case, the regex used in the second rule, simply ^
, is "better" as it's more efficient (net result is the same).
Note that the two RewriteRule
directives are really "the same" - in what they actually do (they request the HTTPS version). It's just the preceding condition (RewriteCond
directive) that varies.
Note also, that this is "only" an HTTP to HTTPS redirect. It doesn't, for example, canonicalise the www vs non-www subdomain. Some would argue that you should combine these two tasks into a single rule/redirect. Although that still isn't necessarily "better".
add a comment
|
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "45"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fwebmasters.stackexchange.com%2fquestions%2f125446%2fforcing-all-requests-to-https-vs-not-forcing-all-requests%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I read a lot of pages and thought I had a firm grasp on what to add to
htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
Exactly what directives you need to use can depend on your server configuration. And to some extent personal preference (eg. whether you check the HTTPS
server variable or SERVER_PORT
).
These directives (checking against the HTTPS
server variable) are arguably the most common and should work when the SSL cert is installed directly on the application server (as opposed to a front-end proxy). This should be your goto HTTP to HTTPS redirect (but note the optimisation mentioned below*1).
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Yes, it would - providing they are the correct directives for your server config. The .htaccess
file is processed for all HTTP requests and that includes 1, 2 and 3.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule.
Without seeing the article in question; that is incorrect. When a user "types a URL manually", it's an HTTP request just like any other.
The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
These directives should only be used if the HTTPS connection (SSL cert) is being handled by a front-end proxy. If not, then you will most certainly get a redirect loop. The condition above checks the X-Forwarded-Proto
HTTP request header - which would ordinarily be set by a proxy server.
Likewise, if you used the first rule block that checks against the HTTPS
server variable on a server that uses a front-end proxy to handle the secure connection then you would also likely get a redirect loop.
Always test with 302 (temporary) redirects if in any doubt.
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)?
Yes, you should also change the wp-config. At the very least, it is a failsafe. But also, you don't want the situation when you are redirecting to HTTPS and WP is redirecting back to HTTP. (I'm not actually sure whether that would happen, but it is certainly true the other way round.)
if there is a better condition/rule to use than those noted above let me know.
As noted above, any one way is not necessarily "better". Its what works for you.
*1 However, there are small optimisations that can be made in the directive(s) you posted. For example, in your first rule, you use the less efficient regex ^(.*)$
. This regex traverses the entire string and captures the entire match in a backreference. This is unnecessary in the context it is being used. You aren't using any backreferences in the substitution and you simply need to trigger the rule for anything. In which case, the regex used in the second rule, simply ^
, is "better" as it's more efficient (net result is the same).
Note that the two RewriteRule
directives are really "the same" - in what they actually do (they request the HTTPS version). It's just the preceding condition (RewriteCond
directive) that varies.
Note also, that this is "only" an HTTP to HTTPS redirect. It doesn't, for example, canonicalise the www vs non-www subdomain. Some would argue that you should combine these two tasks into a single rule/redirect. Although that still isn't necessarily "better".
add a comment
|
I read a lot of pages and thought I had a firm grasp on what to add to
htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
Exactly what directives you need to use can depend on your server configuration. And to some extent personal preference (eg. whether you check the HTTPS
server variable or SERVER_PORT
).
These directives (checking against the HTTPS
server variable) are arguably the most common and should work when the SSL cert is installed directly on the application server (as opposed to a front-end proxy). This should be your goto HTTP to HTTPS redirect (but note the optimisation mentioned below*1).
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Yes, it would - providing they are the correct directives for your server config. The .htaccess
file is processed for all HTTP requests and that includes 1, 2 and 3.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule.
Without seeing the article in question; that is incorrect. When a user "types a URL manually", it's an HTTP request just like any other.
The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
These directives should only be used if the HTTPS connection (SSL cert) is being handled by a front-end proxy. If not, then you will most certainly get a redirect loop. The condition above checks the X-Forwarded-Proto
HTTP request header - which would ordinarily be set by a proxy server.
Likewise, if you used the first rule block that checks against the HTTPS
server variable on a server that uses a front-end proxy to handle the secure connection then you would also likely get a redirect loop.
Always test with 302 (temporary) redirects if in any doubt.
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)?
Yes, you should also change the wp-config. At the very least, it is a failsafe. But also, you don't want the situation when you are redirecting to HTTPS and WP is redirecting back to HTTP. (I'm not actually sure whether that would happen, but it is certainly true the other way round.)
if there is a better condition/rule to use than those noted above let me know.
As noted above, any one way is not necessarily "better". Its what works for you.
*1 However, there are small optimisations that can be made in the directive(s) you posted. For example, in your first rule, you use the less efficient regex ^(.*)$
. This regex traverses the entire string and captures the entire match in a backreference. This is unnecessary in the context it is being used. You aren't using any backreferences in the substitution and you simply need to trigger the rule for anything. In which case, the regex used in the second rule, simply ^
, is "better" as it's more efficient (net result is the same).
Note that the two RewriteRule
directives are really "the same" - in what they actually do (they request the HTTPS version). It's just the preceding condition (RewriteCond
directive) that varies.
Note also, that this is "only" an HTTP to HTTPS redirect. It doesn't, for example, canonicalise the www vs non-www subdomain. Some would argue that you should combine these two tasks into a single rule/redirect. Although that still isn't necessarily "better".
add a comment
|
I read a lot of pages and thought I had a firm grasp on what to add to
htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
Exactly what directives you need to use can depend on your server configuration. And to some extent personal preference (eg. whether you check the HTTPS
server variable or SERVER_PORT
).
These directives (checking against the HTTPS
server variable) are arguably the most common and should work when the SSL cert is installed directly on the application server (as opposed to a front-end proxy). This should be your goto HTTP to HTTPS redirect (but note the optimisation mentioned below*1).
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Yes, it would - providing they are the correct directives for your server config. The .htaccess
file is processed for all HTTP requests and that includes 1, 2 and 3.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule.
Without seeing the article in question; that is incorrect. When a user "types a URL manually", it's an HTTP request just like any other.
The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
These directives should only be used if the HTTPS connection (SSL cert) is being handled by a front-end proxy. If not, then you will most certainly get a redirect loop. The condition above checks the X-Forwarded-Proto
HTTP request header - which would ordinarily be set by a proxy server.
Likewise, if you used the first rule block that checks against the HTTPS
server variable on a server that uses a front-end proxy to handle the secure connection then you would also likely get a redirect loop.
Always test with 302 (temporary) redirects if in any doubt.
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)?
Yes, you should also change the wp-config. At the very least, it is a failsafe. But also, you don't want the situation when you are redirecting to HTTPS and WP is redirecting back to HTTP. (I'm not actually sure whether that would happen, but it is certainly true the other way round.)
if there is a better condition/rule to use than those noted above let me know.
As noted above, any one way is not necessarily "better". Its what works for you.
*1 However, there are small optimisations that can be made in the directive(s) you posted. For example, in your first rule, you use the less efficient regex ^(.*)$
. This regex traverses the entire string and captures the entire match in a backreference. This is unnecessary in the context it is being used. You aren't using any backreferences in the substitution and you simply need to trigger the rule for anything. In which case, the regex used in the second rule, simply ^
, is "better" as it's more efficient (net result is the same).
Note that the two RewriteRule
directives are really "the same" - in what they actually do (they request the HTTPS version). It's just the preceding condition (RewriteCond
directive) that varies.
Note also, that this is "only" an HTTP to HTTPS redirect. It doesn't, for example, canonicalise the www vs non-www subdomain. Some would argue that you should combine these two tasks into a single rule/redirect. Although that still isn't necessarily "better".
I read a lot of pages and thought I had a firm grasp on what to add to
htaccess which was along the lines of...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
Exactly what directives you need to use can depend on your server configuration. And to some extent personal preference (eg. whether you check the HTTPS
server variable or SERVER_PORT
).
These directives (checking against the HTTPS
server variable) are arguably the most common and should work when the SSL cert is installed directly on the application server (as opposed to a front-end proxy). This should be your goto HTTP to HTTPS redirect (but note the optimisation mentioned below*1).
I assumed (maybe incorrectly) that this handled all of my requirements (that being 1. Tell the search engines to switch, 2. Catch visitors with old bookmarks and 3. Catch people who type in a URL that they've memorized). I thought the above forced all requests.
Yes, it would - providing they are the correct directives for your server config. The .htaccess
file is processed for all HTTP requests and that includes 1, 2 and 3.
Then I came across an article that seemed to suggest that people who type in a URL manually will not be redirected by just using the above condition/rule.
Without seeing the article in question; that is incorrect. When a user "types a URL manually", it's an HTTP request just like any other.
The article said to force all requests with...
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
These directives should only be used if the HTTPS connection (SSL cert) is being handled by a front-end proxy. If not, then you will most certainly get a redirect loop. The condition above checks the X-Forwarded-Proto
HTTP request header - which would ordinarily be set by a proxy server.
Likewise, if you used the first rule block that checks against the HTTPS
server variable on a server that uses a front-end proxy to handle the secure connection then you would also likely get a redirect loop.
Always test with 302 (temporary) redirects if in any doubt.
Is changing the wp-config needed if htaccess is being used or is it a good idea to have both (maybe wp-config acts as a failsafe)?
Yes, you should also change the wp-config. At the very least, it is a failsafe. But also, you don't want the situation when you are redirecting to HTTPS and WP is redirecting back to HTTP. (I'm not actually sure whether that would happen, but it is certainly true the other way round.)
if there is a better condition/rule to use than those noted above let me know.
As noted above, any one way is not necessarily "better". Its what works for you.
*1 However, there are small optimisations that can be made in the directive(s) you posted. For example, in your first rule, you use the less efficient regex ^(.*)$
. This regex traverses the entire string and captures the entire match in a backreference. This is unnecessary in the context it is being used. You aren't using any backreferences in the substitution and you simply need to trigger the rule for anything. In which case, the regex used in the second rule, simply ^
, is "better" as it's more efficient (net result is the same).
Note that the two RewriteRule
directives are really "the same" - in what they actually do (they request the HTTPS version). It's just the preceding condition (RewriteCond
directive) that varies.
Note also, that this is "only" an HTTP to HTTPS redirect. It doesn't, for example, canonicalise the www vs non-www subdomain. Some would argue that you should combine these two tasks into a single rule/redirect. Although that still isn't necessarily "better".
edited 5 hours ago
answered 7 hours ago
MrWhiteMrWhite
32.8k3 gold badges35 silver badges69 bronze badges
32.8k3 gold badges35 silver badges69 bronze badges
add a comment
|
add a comment
|
Thanks for contributing an answer to Webmasters Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fwebmasters.stackexchange.com%2fquestions%2f125446%2fforcing-all-requests-to-https-vs-not-forcing-all-requests%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Welcome to Webmasters!
– closetnoc
8 hours ago