FastCGI: SCRIPT_NAME must have leading slash (or be empty)

[sorbits]

I have /index.php that serves requests for non-existing files (custom router).

When requesting / then SCRIPT_NAME is correctly set to /index.php, but when requesting e.g. /about then SCRIPT_NAME is index.php (notice that there is no leading slash).

According to RFC3875 then SCRIPT_NAME must either be empty, or have a leading slash:

The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded)
which could identify the CGI script (rather than the script's
output).  The syntax is the same as for PATH_INFO (section 4.1.5)

   SCRIPT_NAME = "" | ( "/" path )

The leading "/" is not part of the path.  It is optional if the path
is NULL; however, the variable MUST still be set in that case.

The SCRIPT_NAME string forms some leading part of the path component
of the Script-URI derived in some implementation-defined manner.  No
PATH_INFO segment (see section 4.1.5) is included in the SCRIPT_NAME
value.

It is causing a compatibility problem with a PHP framework that calls dirname on the value of SCRIPT_NAME.

[francislavoie]

Okay, that should be an easy fix. It's because of the try_files built into the php_fastcgi directive rewrites to index.php as a fallback but not /index.php.

See here: https://caddyserver.com/docs/caddyfile/directives/php_fastcgi#expanded-form

I'd still consider that a minor bug in that framework though, it works with every other framework we've thrown at it so far (Laravel, Symfony, Wordpress, etc.)

[francislavoie]

The more "correct" change is to change it at the actual fastcgi implementation to ensure the trailing slash is kept. I did both in the PR but I might remove the first change since it shouldn't really be necessary.