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: Not a bug
Type: Bug
Package: Built-in web server
Operating System: Debian GNU/Linux jessie x64
PHP Version: 5.6.0RC2
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> PHP assumes a path part with a dot is a file. That assumption is not
> necessarily right.
I agree, and if the built in webserver actually behaves this way, I
think that is a bug (please open another ticket for this).
> PHP can maintain this "dot in a path is a file" assumption but instead
> of returning the 404 error it should route to router script.
It appears there is a misconception regarding router scripts. These are
*always* executed *before* the requested document is served; they do not
work as fallback for 404 (or other) error cases.
Previous Comments:
------------------------------------------------------------------------
[2016-11-02 16:45:09] aljosha dot papsch at vinexus dot eu
This is totally a bug. PHP assumes a path part with a dot is a file. That assumption is not
necessarily right. It should be up to application to decide what to do.
PHP can maintain this "dot in a path is a file" assumption but instead of returning the
404 error it should route to router script.
------------------------------------------------------------------------
[2015-09-05 17:22:05] cmb@php.net
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.
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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