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;
}








2















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.










share|improve this question



























  • Welcome to Webmasters!

    – closetnoc
    8 hours ago


















2















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.










share|improve this question



























  • Welcome to Webmasters!

    – closetnoc
    8 hours ago














2












2








2








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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • Welcome to Webmasters!

    – closetnoc
    8 hours ago

















Welcome to Webmasters!

– closetnoc
8 hours ago





Welcome to Webmasters!

– closetnoc
8 hours ago










1 Answer
1






active

oldest

votes


















1

















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






share|improve this answer





























    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
    });


    }
    });















    draft saved

    draft discarded
















    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









    1

















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






    share|improve this answer
































      1

















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






      share|improve this answer






























        1














        1










        1










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






        share|improve this answer
















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







        share|improve this answer














        share|improve this answer



        share|improve this answer








        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


































            draft saved

            draft discarded



















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

            Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

            Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...