Bug #67671 [Opn->Nab]: mod_rewrite emulation fails for paths with dots in them

Edit report at https://bugs.php.net/bug.php?id=67671&edit=1 ID: 67671 Updated by: cmb@php.net Reported by: tobias at twokings dot nl Summary: mod_rewrite emulation fails for paths with dots in them -Status: Open +Status: Not a bug Type: Bug Package: Built-in web server Operating System: Debian GNU/Linux jessie x64 PHP Version: 5.6.0RC2 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: Firstly, the built-in webserver does not support .htaccess, let alone any rewrite rules. This is unlikely to change, and certainly not a bug. What happens in your case? Requesting <http://localhost/> delivers index.php, as expected. If <http://localhost/asdf.foo> is requested, the server responds with 404 Not found, what is also expected, because the resource doesn't exist. However, if <http://localhost/asdf> is requested, the server delivers index.php in the docroot, what is a bug, namely bug #70434. Previous Comments: ------------------------------------------------------------------------ [2015-02-18 19:38:50] cmbecker69 at gmx dot de > Note, specifically, that the built-in server *does* support > RewriteRules; it parses .htaccess and processes it correctly. I strongly doubt that. It might be possible to use a router script that caters to .htaccess, though. ------------------------------------------------------------------------ [2014-07-28 09:26:46] tobias at twokings dot nl > It's not a bug. If it's not a bug, then it is an undocumented feature that is different from the default behavior of emulating Apache + mod_php. The built-in web server emulates RewriteRules just fine, *except* when the HTTP path contains a dot, in which case it assumes that we want to serve a static file. In other words, what seems to happen here is that the static file detection happens *before* processing rewrites, while in Apache, it happens *after* (or rather, Apache resolves rewrites, then maps the resulting request path to filesystem paths, potentially with MultiViews changing the extension based on acceptable content types, and then determines, based on the file it finds, how to process the result). Note, specifically, that the built-in server *does* support RewriteRules; it parses .htaccess and processes it correctly. Either way, whether the request URL contains a dot is completely orthogonal to static file detection: I may want to serve a file named README statically under /README, and /domain-info/example.org could be a dynamic URL that I want to process *exactly* like /domain-info/all-domains. > If you want to force the entry point (ot emulate a RewriteRule) you need to fire up the server > in this way That is hardly a solution. I do not want to force an entry point for everything, the example is just a minimum viable Rewrite configuration to demonstrate the problem. In my real-world example, this won't work at all, because I need to rewrite more specifically, leaving some static files actually served statically. The built-in server *does* support RewriteRule (see above), and the problem is not with those - RewriteRules are merely a triggering circumstance, but the root problem is that the built-in server uses a flawed mechanism to determine whether something should be served statically or not. Anyway; the point of the built-in web server is to test PHP scripts locally, and any undocumented deviation from a reasonably standard Apache setup is highly undesirable for that, because if the test server doesn't match the production system on key aspects like this one, why bother using it at all? ------------------------------------------------------------------------ [2014-07-25 05:06:29] genesislive2007 at gmail dot com It's not a bug. If you want to force the entry point (ot emulate a RewriteRule) you need to fire up the server in this way: php -S localhost:8000 -t dir dir/index.php ------------------------------------------------------------------------ [2014-07-23 21:29:31] requinix@php.net Still unsure how to reproduce (and my brain is completely failing to read C right now) but that code certainly does look responsible for it. ------------------------------------------------------------------------ [2014-07-23 20:10:29] genesislive2007 at gmail dot com tring to fix it with this PR: https://github.com/php/php-src/pull/738 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=67671 -- Edit this bug report at https://bugs.php.net/bug.php?id=67671&edit=1