Rewrite before regex location

Joyce Babu joyce at joycebabu.com
Wed May 4 23:43:29 UTC 2016


>
> If you've got a messy config with no common patterns, you've got a messy
> config with no common patterns, and there's not much you can do about it.
>
> If you can find common patterns, maybe you can make the config more
> maintainable (read: no top-level regex locations); but you don't want
> to break previously-working urls.
>

The site was initially using Apache + mod_php. Hence these ere not an
issue. It was only when
I tried to migrate to PHP-FPM, I realized the mistakes. Now the urls cannot
be chanced due to
SEO implications.


>
> > I tried using ^~ as you suggested. Now the rewrite is working correctly,
> > but the files are not executed. The request is returning the actual PHP
> > source file, not the HTML generated by executing the script.
>
> Can you show one configuration that leads to the php content being
> returned?
>
> If you rewrite /test/x.php to /test.php, /test.php should be handled in
> the "~ php" location.
>

I am sorry, I did not rewrite it to a location outside /test/, which was
why the file content was being returned.

Is it possible to do something like this?

location /test/ {
    rewrite "^/test/([a-z]+).php$" /php-fpm/test/test.php?q=$1 last;
}

location ~ ^/php-fpm/ {
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^/php-fpm(.+?\.php)(/.*)$;

        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi_params;
    }
}


What I have tried to do here is rewrite to add a special prefix (/php-fpm)
to the rewritten urls. and nest the php location block within it. Then use
fastcgi_split_path_info to create new $fastcgi_script_name without the
special prefix. I tried the above code, but it is not working.
fastcgi_split_path_info is not generating $fastcgi_script_name without the
/php-fpm prefix.



> An alternative possibility could be to put these rewrites at server
> level rather than inside location blocks. That is unlikely to be great
> for efficiency; but only you can judge whether it could be adequate.
>
> > > > location ~ [^/]\.php(/|$) {
> > > >     fastcgi_split_path_info ^(.+?\.php)(/.*)$;
> > > >
> > > >     set $fastcgi_script_name_custom $fastcgi_script_name;
> > > >     if (!-f $document_root$fastcgi_script_name) {
> > > >         set $fastcgi_script_name_custom "/cms/index.php";
> > > >     }
> > >
> > > I suspect that it should be possible to do what you want to do there,
> > > with a "try_files". But I do not know the details.
> >
> > There is a CMS engine which will intercept all unmatched requests and
> check
> > the database to see if there is an article with that URI. Some times it
> has
> > to match existing directories without index.php. If I use try_files, it
> > will either lead to a 403 error (if no index is specified), or would
> > internally redirect the request to the index file (if it is specified),
> > leading to 404 error. The if condition correctly handles all the
> > non-existing files.
>
> There is more than one possible try_files configuration; but that does not
> matter: if you have a system that works for you, you can keep using it.
>
> Good luck with it,
>
>         f
> --
> Francis Daly        francis at daoine.org
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160505/d1dfbb7b/attachment.html>


More information about the nginx mailing list