Allow internal redirect to URI x, but deny external request for x?

J. Lewis Muir jlmuir at
Fri Aug 30 21:59:36 UTC 2019

On 08/30, Francis Daly wrote:
> On Fri, Aug 30, 2019 at 01:58:23PM -0500, J. Lewis Muir wrote:
> Hi there,
> >   location ~ ^/my-app/(.*?[^/]\.php(?:/.*|$)) {
> >     alias /srv/www/my-app/current/$1;
> >     fastcgi_split_path_info ^(.+?\.php)(/.*)$;
> >     return 200 "realpath_root: $realpath_root\nfastcgi_script_name: $fastcgi_script_name\nfastcgi_path_info: $fastcgi_path_info\n";
> >   }
> > 
> > which yields the following:
> > 
> >   $ curl http://localhost/my-app/
> >   realpath_root: /srv/www/my-app/releases/1.0.2/index.php
> >   fastcgi_script_name: /my-app/index.php
> >   fastcgi_path_info:
> > 
> > That doesn't seem right.
> Why not?
>$realpath_root says is it the current root or alias
> value, resolving symlinks.
> The request was /my-app/, the current request is /my-app/index.php,
> and you have alias'ed that to /srv/www/my-app/current/index.php
Yes, you're absolutely right.  This is where I went wrong.  I was
initially wishing to use the root directive

  location ~ ^/my-app/(.*?[^/]\.php(?:/.*|$)) {
    root /srv/www/my-app/current;
    include php-fpm-realpath.conf;

but then the URI would be appended to that, so for a request of


it would result in


which wasn't what I wanted; instead I wanted


I was wishing for a way to specify a new root but with a modified
request URI.  So, I tried the alias directive, and I assumed that
$document_root and $realpath_root would refer to the aliased document
root, but obviously that can't be since nginx has no way of knowing what
the aliased document root should be when all it has is a location alias
which is the full path to the resource.  Sorry for the trouble.

>$fastcgi_script_name (and what follows) describes
> the other variables.
> The request is /my-app/index.php and your fastcgi_split_path_info sets
> $fastcgi_script_name to "everything up to .php" and $fastcgi_path_info to
> "everything after .php", so long as .php is followed by / -- which it
> isn't, so both are unchanged from their defaults of "the uri" and "empty".
> (I'm somewhat guessing about the last part there; a test can probably
> demonstrate whether it is incorrect.)

Yep, I'm sure you're right here as well.  Sorry for the trouble; I just
totally missed how this worked.

Thank you for your help!


More information about the nginx mailing list