[wp-trac] [WordPress Trac] #14880: 404 Errors Replaced with Category Pages

[WordPress Trac]

#14880: 404 Errors Replaced with Category Pages
---------------------------+------------------------------------------------
 Reporter:  askapache      |        Owner:  scribu  
     Type:  defect (bug)   |       Status:  reopened
 Priority:  normal         |    Milestone:  3.1     
Component:  Query          |      Version:  3.1     
 Severity:  major          |   Resolution:          
 Keywords:  parse_request  |  
---------------------------+------------------------------------------------
Changes (by askapache):

  * keywords:  => parse_request
  * severity:  normal => major


Comment:

 Ok I have traced this error back to the

 function parse_request

 in wp-includes/class-wp.php

 The logic is bad. Looks like someone made some updates to other parts of
 the function and forgot to test the error is still getting saved.

 And the code looks like it really only cares about 404 errors, not the
 whole spectrum of http error codes as defined by the status_header
 function.  There are 53 status codes, and all HTTP error codes that start
 with a 4 or a 5 should definately be counted by WP, and would be if this
 is fixed and the user is using a smart plugin or 404.php template.

 A url like /e=405/e=405/?error=405&e=405 should set the error to 405 in
 the query_vars and cause the is_404 function to be set.

 It seems from my debugging that before the error can be set and triggered,
 it is deleted.  IOW, the $_GET['error'] is unset as well as the $error (in
 parse_request).

 This is a big problem for any server that is running Apache.  A serious
 problem.  For instance, instead of responding correctly to an "OPTIONS *
 HTTP/1.1" request that isn't allowed with a 405 Method Not Allowed, this
 parse_request code causes the entire front-page of my blog to be
 displayed.

 Several other problems crop up, especially when dealing with search
 engines, the way-back archive machine, and others.

 I definately think this should be fixed in the core, and not left up to
 plugin authors to set via filtering query vars, this will get messy quick
 if that were to happen, and would cause problems with alot of currently
 useful widespread plugins.

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