Fix PHP PATH_INFO

[francescom]

The PHP PATH_INFO is a well established although not often used mechanism, supported by most webserver, and even when it is not supported it is patchable so that it works.

You can add data after the base url and before the GET parameters. When you call a page like this

path/to/page.php/some/path/info?parameter=value

PHP will put the string 'some/path/info' into $_SERVER['PATH_INFO].

Without this patch Valet tries to find the file path/to/page.php/some/path/info on disk, without finding it and returning a 404.

The patch removes the PATH_INFO string from $_SERVER['REQUEST_URI'] at the very beginning of server.php so Valet can find the correct file, then recovers the original $_SERVER['REQUEST_URI'] just before the final require.

Although the PATH_INFO mechanism is not often known and used, it is sometimes useful and there is no reason not to follow PHP on this, by failing to include the correct file.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[mattstauffer]

Hey @francescom, as far as I can tell PATH_INFO is not usually set on default Nginx configurations; you have to do some work to manually set it in Nginx, and it's really only mainly used in Apache.

Valet uses Nginx, in part with the intention to mimic the most common deploy environments for Laravel, so I'm not super interested in patching it to be a non-standard Nginx installation--I think that sort of thing makes it more likely people will get a mismatch between their local and their deploy setting.

Is there any reason this is not something you can fix in userland, by creating a custom driver?

Thanks!

[francescom]

Hey @francescom, as far as I can tell PATH_INFO is not usually set on default Nginx configurations; you have to do some work to manually set it in Nginx, and it's really only mainly used in Apache.

Valet uses Nginx, in part with the intention to mimic the most common deploy environments for Laravel, so I'm not super interested in patching it to be a non-standard Nginx installation--I think that sort of thing makes it more likely people will get a mismatch between their local and their deploy setting.

Is there any reason this is not something you can fix in userland, by creating a custom driver?

Thanks!

Hello, thanks for your reply.

Even if it is not suèpported by the webserver there is always a shim in PHP than can be written to recreate it from the URI so it basically works.

The problem with the Valet approach is that, as it really looks for the existance of the phisical file page.php/path/info that does not exist, it gives a 404 and the target PHP page is never reached.

With the inclosed patch it looks for the existance of page.php finds it and only then restores the uri to page.php/path/info.

I am pretty sure there are better way to do it fixing the Valet internals but I have little knowledge of those and didn't want to mess up.