[5.7] Remove fastcgi_split_path_info

[0xb4lint]

Currently nginx PHP location block is configured to handle requests with .php ending (location ~ \.php$ {}).
Still there is the widely used fastcgi_split_path_info directive included with the standard ^(.+\.php)(/.+)$ value.
This statement doesn't make any sense, since there is nothing to split after .php.
As far as I know this should be used only in legacy routing systems: index.php/foo/bar.

[taylorotwell]

We still use it on Forge and it works fine?

[0xb4lint]

@taylorotwell what's the purpose of using an nginx directive which has no effect?
These two regex is conflicting with each other \.php$ vs. ^(.+\.php)(/.+)$.
The first one is restricting the handled request path, so the second one has nothing to do with it.

[0xb4lint]

From the nginx docs:

Syntax: fastcgi_split_path_info regex;
Default: —
Context: location

Defines a regular expression that captures a value for the $fastcgi_path_info variable. The regular expression should have two captures: the first becomes a value of the $fastcgi_script_name variable, the second becomes a value of the $fastcgi_path_info variable. For example, with these settings

location ~ ^(.+\.php)(.*)$ {
    fastcgi_split_path_info       ^(.+\.php)(.*)$;
    fastcgi_param SCRIPT_FILENAME /path/to/php$fastcgi_script_name;
    fastcgi_param PATH_INFO       $fastcgi_path_info

and the “/show.php/article/0001” request, the SCRIPT_FILENAME parameter will be equal to “/path/to/php/show.php”, and the PATH_INFO parameter will be equal to “/article/0001”.

As you can see the effective prerequisite of using fastcgi_split_path_info would be a location block allowing paths after the .php extension.

[0xb4lint]

@taylorotwell could you please reconsider this PR?
I truly believe this would be a logical step for Laravel (or for any modern PHP framework).