[wp-trac] [WordPress Trac] #20109: Valid htaccess rule causes 404 after upgrade to 3.3.1

WordPress Trac wp-trac at lists.automattic.com
Mon Feb 27 19:42:30 UTC 2012


#20109: Valid htaccess rule causes 404 after upgrade to 3.3.1
---------------------------+------------------------------
 Reporter:  ronnieg        |       Owner:
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Rewrite Rules  |     Version:  3.3.1
 Severity:  critical       |  Resolution:
 Keywords:                 |
---------------------------+------------------------------
Changes (by ronnieg):

 * keywords:  reporter-feedback =>


Comment:

 Replying to [comment:1 duck_]:

 The rewrite bypass rules above were in the middle of .htaccess, before the
 WP index.php rules. Because all of the rules in the file refered to pages,
 not posts, the rules were all working, and are still working, converting
 incoming old urls to new page urls prior to hitting the WP index.php
 rules.

 The behavior I was seeing was really bizarre, because the good and
 intended content is definitely being rendered, not an empty page and not
 the standard or custom 404 page. For the purpose of demonstrating this, I
 am putting just the areas rule above back into the .htaccess file of my
 3.3.1 development environment, with no other url specific rules. So to see
 this behavior in action, go to: http://dev1.denverhomevalue.com/areas
 /denver-central-communities.html.

 You will see the full and correct content for that page, but with a 404
 header response. You should see the same kind of behavior on all pages
 under the "Metro Areas" menu category, but normal 200 responses to
 everything else in the other menu categories.

 Really, regardless of what earlier release this affects, which my own
 experience and testing shows was not an issue in the production/stable
 version of 3.2.1 I was on, 3.3 actually renders proper content, while
 improperly returning a 404 header, and that to me is the root issue,
 regardless of whether the WP index.php rewrite rules are going to be hit
 or not. Essentially, if content is successfully rendered, as my dev1 site
 proves is happening, then 200 should be the response. Only if content
 cannot be successfully rendered should it invoke a 404 response, and that
 should also trigger the standard or custom 404 action for the site.

 The complete .htaccess currently on the above dev site follows:

 {{{
 RewriteEngine On
 RewriteBase /
 <IfModule mod_rewrite.c>
 ########## Begin - Rewrite rules to block out some common exploits
 ## This attempts to block the most common type of exploit `attempts`
 #
 # Block out any script trying to set a mosConfig value through the URL
 RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
 # Block out any script trying to base64_encode crap to send via URL
 RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
 # Block out any script that includes a <script> tag in URL
 RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
 # Block out any script trying to set a PHP GLOBALS variable via URL
 RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
 # Block out any script trying to modify a _REQUEST variable via URL
 RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
 # Send all blocked request to homepage with 403 Forbidden error!
 RewriteRule ^(.*)$ index.php [F,L]
 RewriteRule ^areas(.*) - [L]
 # BEGIN WordPress
 RewriteEngine On
 RewriteBase /
 RewriteRule ^index\.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /index.php [L]
 </IfModule>
 }}}

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/20109#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list