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;









2















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















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








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
















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

















  • 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


















2

















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









    2

















    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































      2

















      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





























        2














        2










        2










        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

            Canceling a color specificationRandomly assigning color to Graphics3D objects?Default color for Filling in Mathematica 9Coloring specific elements of sets with a prime modified order in an array plotHow to pick a color differing significantly from the colors already in a given color list?Detection of the text colorColor numbers based on their valueCan color schemes for use with ColorData include opacity specification?My dynamic color schemes

            Invision Community Contents History See also References External links Navigation menuProprietaryinvisioncommunity.comIPS Community ForumsIPS Community Forumsthis blog entry"License Changes, IP.Board 3.4, and the Future""Interview -- Matt Mecham of Ibforums""CEO Invision Power Board, Matt Mecham Is a Liar, Thief!"IPB License Explanation 1.3, 1.3.1, 2.0, and 2.1ArchivedSecurity Fixes, Updates And Enhancements For IPB 1.3.1Archived"New Demo Accounts - Invision Power Services"the original"New Default Skin"the original"Invision Power Board 3.0.0 and Applications Released"the original"Archived copy"the original"Perpetual licenses being done away with""Release Notes - Invision Power Services""Introducing: IPS Community Suite 4!"Invision Community Release Notes

            199年 目錄 大件事 到箇年出世嗰人 到箇年死嗰人 節慶、風俗習慣 導覽選單