Clean-URL rewrite rule with nested "location" and alias directive

Ben Johnson ben at indietorrent.org
Sat Nov 23 18:11:46 UTC 2013



On 11/23/2013 12:36 PM, Ben Johnson wrote:
> Okay, I'm trying to implement this, but something seems to have gone
> terribly awry. I apologize for derailing our progress, but until this is
> resolved, I have no way to test your recommendations.
> 
> It's bizarre. At some point while meddling with the configuration,
> requests for /stage/ began causing the browser to download index.php
> (and I can open the file and see the PHP code). And no matter what I
> change in the configuration, this behavior persists.
> 
> I went so far as to rename the "stage" directory to "staging", and
> changed all references in nginx's configuration accordingly. Yet, for
> some reason, requests for /stage/ still download the index.php file! I'm
> not even sure where this index.php file is coming from, given that nginx
> should have absolutely no knowledge of this file's new/current location.
> 
> The weirdest part is that the downloaded file is *not* the file that
> exists at /index.php (the "main site" index file). I confirmed this by
> adding some commented PHP code at the bottom of /index.php, and the
> comments do not appear in the downloaded file.
> 
> Hell, I even tried deleting the entire "staging" directory and this
> still happens! I've restarted nginx, php5-fpm, etc. and nothing changes.
> Where is this file coming from???

I removed everything related to this effort (setting-up the staging
site) from nginx's configuration, and deleted all of the staging site
files from the filesystem, yet nginx is still serving an "index.php"
file whenever I request /stage/! How is this possible? This "index.php"
is indeed "mine"; it contains the code from my application. But, as I
said, if I add some random, commented PHP code to the bottom of the
"real index file" at /index.php, it's not present in the downloaded
file. I just don't see where this file could be coming from at this point.

If I request some other URL, e.g., /stag/, this does not happen; the
problem is specific to the location /stage/.

grep -ir "stage" /etc/nginx does not return any results, either, which
proves that all references to this location have been expunged from the
nginx configuration.

Furthermore, any effort to modify the configuration to use a different
location, such as /staging/ has no effect. It's like the nginx
configuration is stuck in some cached state. And restarting nginx
doesn't fix the problem.

Am I out of my mind?

Thanks for any insight as to what could be happening here...

-Ben



More information about the nginx mailing list