#10743 closed defect (bug) (worksforme)
WP rewrite rule bug with & in url path
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Permalinks | Keywords: | |
Focuses: | Cc: |
Description
We've noticed a peculiar bug in the standard rewrite rules for wp if & is included in any url, as part of the path, not the query string.
EGs:
The rewrite rule serves the default page, without returning a 404.
My best guess at this time is that what is happening is that the inclusion of & in a rewritten path is actually seen as a query param (eg: treated as /index.php? =...)
Attachments (1)
Change History (14)
#4
@
16 years ago
Do setups that don't use mod_rewrite experience the same problem (pathinfo, IIS rewrite). If so we should solve it in WP's query handler.
#5
@
16 years ago
Perhaps $_SERVERQUERY_STRING? is being set for these requests, thus confusing WP::handle_404().
#6
@
16 years ago
- instances without mod_rewrite: in my test, the problem did not affect these
- query_string: indeed, that is the source of the issue. I tried other ways, such a suggested fix for MediaWiki (http://www.mediawiki.org/wiki/Manual:Short_URL/Ampersand_solution), but the above is what worked best, again, in my tests.
#7
@
16 years ago
As far as having the fix in the query handler: there are up and down sides to that, but it'd be just as valid a solution, and if nothing else, it'd be easier to control, and for upgrades, since a .htaccess solution (as provided in patch) would have the downside of people having to physically go to the permalinks settings page and re-saving their configs (unless handled in the upgrade, which unless I'm mistaken, isn;t a best practice).
#8
@
16 years ago
And although it's not a core thing, we might also want to try things out with donncha's wp-super-cache.
#10
@
15 years ago
- Keywords needs-patch added; has-patch removed
- Milestone changed from 3.0 to Future Release
No patch, moving out of 3.0 for now.
#12
@
11 years ago
- Resolution set to worksforme
- Status changed from assigned to closed
This problem is already solved in 4.0. Looks like a simple patch to the WP_MatchesMapRegex()
class solved the problem:
public function callback($matches) { $index = intval(substr($matches[0], 9, -1)); return ( isset( $this->_matches[$index] ) ? urlencode($this->_matches[$index]) : '' ); }
The urlencode bit, on the return line, resolves the & issue.
This should be closed.
So, a bit of context: we found the above issue when the msn bot got stuck in an infinite loop on an install because of a bad link from somwhere that ended up being sent to the server as " /blah" instead of "/blah".
Having the & anywhere else in the url does not create an issue, only when the 1st character after the root of the wp install.
So in my local install, I fixed it with the following rule, which simply redirects offending url to the same one without the ampersand, therefore giving the proper wp 404 response:
As in:
See attached patch for suggested wp-includes/rewrite.php fix.