RewriteCond in .htaccess with negated regex condition doesn't work?

后端 未结 4 1951
野的像风
野的像风 2020-12-30 03:25

I\'m trying to prevent, in this case WordPress, from rewriting certain URLs. In this case I\'m trying to prevent it from ever handling a request in the uploads directory, an

相关标签:
4条回答
  • 2020-12-30 04:00

    I have found many examples like this when taking a "WordPress First" approach. For example, adding:

    ErrorDocument 404 /error-docs/404.html

    to the .htaccess file takes care of the message ("Additionally, a 404 Not Found error...").

    0 讨论(0)
  • 2020-12-30 04:06

    If /wp-content/uploads/ is really the prefix of the requested URI path, your rule was supposed to work as expected.

    But as it obviously doesn’t work, try not to match the path prefix of the full URI path but only the remaining path without the contextual per-directory path prefix, in case of the .htaccess file in the document root directory the URI path without the leading /:

    RewriteCond $0 !^wp-content/uploads/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule .+ /index.php [L]
    

    If that doesn’t work neither, it would certainly help to get some insight into mod_rewrite’s rewriting process by using its logging feature. So set RewriteLogLevel to a level of at least 4, make your request and take a look at the entries in the log file specified with RewriteLog. There you can see how mod_rewrite handles your request and with RewriteLogLevel greater or equal to 4 you will also see the values of variables like %{REQUEST_URI}.

    0 讨论(0)
  • 2020-12-30 04:23
    <IfModule mod_rewrite.c>
    RewriteEngine On
    
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    RewriteCond %{REQUEST_URI} !^/wp-content/uploads/ [OR]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    
    RewriteRule . /index.php [L]
    </IfModule>
    
    0 讨论(0)
  • 2020-12-30 04:24

    So, after a lot of irritation, I figured out the problem, sort of. As it turned out, the rule in my original question actually did exactly what it was supposed to. So did a number of other ways of doing the same thing, such as

    RewriteRule ^wp-content/uploads/.*$ - [L]
    

    (Mark rule as last if pattern matches) or

    RewriteRule ^wp-content/uploads/.*$ - [S=1]
    

    (Skip the next rule if pattern matches) as well as the negated rule in the question, as mentioned. All of those rules worked just fine, and returned control to Apache without rewriting.

    The problem happened after those rules were processed. Instead, the problem was that I deleted a the default 404.shtml, 403.shtml etc templates that my host provided. If you don't have any .htaccess rewrites, that works just fine; the server will dish up its own default 404 page and everything works. (At least that's what I thought, but in actual fact it was the double error "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.")

    When you do have a .htaccess, on the other hand, it is executed a second time for the 404 page. If the page is there, it will be used, but now, instead the request for 404.shtml was caught by the catch-all rule and rewritten to index.php. For this reason, all other suggestions I've gotten here, or elsewhere, have all failed because in the end the 404 page has been rewritten to index.php.

    So, the solution was simply to restore the error templates. In retrospect it was pretty stupid to delete them, but I have this "start from scratch" mentality. Don't want anything seemingly unnecessary lying around. At least now I understand what was going on, which is what I wanted.

    Finally a comment to Cecil: I never wanted to forbid access to anything, just stop the rewrite from taking place. Not that it matters much now, but I just wanted to clarify this.

    0 讨论(0)
提交回复
热议问题