Forcing all requests to HTTPS vs not forcing all requestsRedirecting 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
Why do English transliterations of Arabic names have so many Qs in them?
Injection from two strings to one string
Is cloning illegal in the Star Trek: TNG continuity?
Can I voluntarily exit from the US after a 20 year overstay, or could I be detained at the airport?
Find the number for the question mark
How to catch creatures that can predict the next few minutes?
SHA3-255, one bit less
Meaning of “up to something”
What are the limits on an impeached and not convicted president?
If LPG gas burners can reach temperatures above 1700 °C, then how do HCA and PAH not develop in extreme amounts during cooking?
A goat is tied to the corner of a shed
Proof of bound on optimal TSP tour length in rectangular region
How do I know how many sub-shells deep I am?
Is there a penalty for switching targets?
What is the next number in the sequence 21, 21, 23, 20, 5, 25, 31, 24, ...?
Can something have more sugar per 100g than the percentage of sugar that's in it?
Does SQL Server's serializable isolation level lock entire table
How to know the size of a package
Power Adapter for Traveling to Scotland (I live in the US)
Would Great Old Ones care about the Blood War?
What's the difference between motherboard and chassis?
Is having your hand in your pocket during a presentation bad?
The work of mathematicians outside their professional environment
How long could a human survive completely without the immune system?
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;
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
|
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
|
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
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 2 mins ago
John Conde♦
84.1k16 gold badges133 silver badges231 bronze badges
84.1k16 gold badges133 silver badges231 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