• Resolved hansnielsen

    (@hansnielsen)


    Hello,

    The redirect code that is placed in my .htaccess file by the Really Simple Security plugin seems to be causing issues with my cache plugin. All pages and posts (except the homepage) on my site are being blocklisted from cache warmup in the cache plugin, and the cache plugin support staff believes it has to do with the .htaccess redirect code.

    This is the code added to my .htaccess file:

    #Begin Really Simple Security
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTP:X-Forwarded-Proto} !https
    RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
    </IfModule>

    Options -Indexes
    #End Really Simple Security

    Is this the correct code? I do not recognize this part of the code:

    RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/

    Has that part of the code been there before? Or has something changed during a plugin update?

    Thanks!

Viewing 15 replies - 1 through 15 (of 16 total)
  • Plugin Support Jarno Vos

    (@jarnovos)

    Hi @hansnielsen,

    This is indeed the correct code, the line you attached has indeed been part of the plugin for a long time (specifically since the introduction of the Let’s Encrypt Wizard, which has been there for years).

    This line basically just means, “do not apply the redirect to requests for /.well-known/acme-challenge/, which is done because that specific path is used by Let’s Encrypt during the process of automated SSL/TLS certificate issuance (or renewal).

    While I wouldn’t initially suspect a mere 301 redirect to https:// in the .htaccess to cause cache issues similar to what you described, I suppose you could try ruling it out as being related by temporarily removing them and checking if the cache issue persists upon doing so.

    If this behavior does persist even though the rules aren’t there anymore, there’s likely something else at play here.

    Kind regards, Jarno

    Thread Starter hansnielsen

    (@hansnielsen)

    Hello @jarnovos and thank you for your quick reply.

    When I disabled redirect in Really Simple Security > Settings > SSL (which removed the code from .htaccess), the issue was not there anymore, and the cache warmup was working again without blocklisting any pages or posts.

    Where do I go from here?

    Thank you!

    Plugin Support Jarno Vos

    (@jarnovos)

    Hi @hansnielsen,

    If your cache plugin doesn’t behave well in combination with the .htaccess 301 redirect, you could try switching to the standard WordPress PHP redirect via the plugin’s settings (Security -> Settings -> SSL -> Redirect Method) instead.

    Kind regards, Jarno

    Thread Starter hansnielsen

    (@hansnielsen)

    Hi @jarnovos

    Yes, that worked.

    Can you please confirm that there has been no changes to the Really Simple Security .htaccess redirect code? I am asking because the issue with the cache plugin has not been there before (= the cache plugin has been working fine with the .htaccess redirect code earlier), so I need to know which info I shall give to the cache plugin staff.

    Thank you.

    Plugin Support Jarno Vos

    (@jarnovos)

    Hi @hansnielsen,

    Indeed, the .htaccess 301 redirect hasn’t changed in recent versions of the plugin; so I can’t really say how that would have changed the caching plugin behavior in the meantime (provided that this is the only difference).

    The WordPress 301 redirect is a perfectly fine alternative though, so it’d be fine to just use that instead.

    Kind regards, Jarno

    • This reply was modified 11 months, 2 weeks ago by Jarno Vos.
    Thread Starter hansnielsen

    (@hansnielsen)

    Great, thank you @jarnovos

    Hello,

    LiteSpeed support staff here as requested by the user to explain the issue 🙂

    the issue is

    RewriteCond %{HTTP:X-Forwarded-Proto} !https

    this condition , it works fine when site is running behind proxy or CDN, the proxy server will send XFP: https header , but in our case, our crawler will send request directly to the origin server , bypass CDN/proxy , as this is a direct connection to the origin server, it does not carry the XFP: https header, thus hit the rule that makes redirection and breaks our function.

    I am not exactly sure how to fix this , offhanded , few thoughts :

    1. add a rule to check if a proxy exists , and only check the xfp if proxy exists
    2. add a whitelist rule to bypass our crawler user agent (LSCache runner)
    3. add a rule to bypass the request sending from server IP itself ( it might be hard to determine which IP sends the request if server contains multiple IPs which is fairly common on shared hosting server )
    • This reply was modified 11 months, 2 weeks ago by qtwrk.
    Plugin Support Jarno Vos

    (@jarnovos)

    Hi @qtwrk,

    I highly appreciate your input here, thanks a lot for chiming in.

    I will put this case up for discussion within our development team to see how we could best address such a situation, but your insights are very much appreciated.

    For the time being though, I expect that the user is best served by reverting to the standard 301 WordPress PHP redirect as this will be an immediate solution to their problem.

    Kind regards, Jarno

    thanks 🙂

    Thread Starter hansnielsen

    (@hansnielsen)

    Hello @pzsniper and @qtwrk

    I actually removed the Really Simple Security plugin, but the issue was still there. Then reinstalled Really Simple Security again.

    Maybe it happens a bit less often without the Really Simple Security plugin, but still there when removing the plugin. I have to try many times with clearing caches, clearing block lists, reloading sitemap, and after a while it works…

    Plugin Support Jarno Vos

    (@jarnovos)

    Hi @hansnielsen

    FYI, we have a fix for this case planned for the next release of the plugin, which will exclude the LSCache Crawler from the redirect in Really Simple Security.

    Kind regards, Jarno

    Thread Starter hansnielsen

    (@hansnielsen)

    That is great, thank you @jarnovos

    Plugin Support Jarno Vos

    (@jarnovos)

    Hi @hansnielsen (cc @pzsniper and @qtwrk),

    I need to correct my previous message: the fix to exclude the LSCache Crawler from the redirect will not be included in the next release as initially planned, but it is scheduled for the release after that.

    Sorry about that!

    Kind regards, Jarno

    Hi,

    Is the latest 9.4.3 finally the fixer for this BIG issue?

    https://prnt.sc/duPmx8NREEd9

    • This reply was modified 10 months, 1 week ago by pzsniper.
Viewing 15 replies - 1 through 15 (of 16 total)

The topic ‘.htaccess redirect code issue?’ is closed to new replies.