Laravel is "listening" to index.php string anywhere in the URL

Question

I have a Laravel 5 project with routes set up as well as a custom 404 page (mostly for missing/incorrect "pages").

So basically if I open any existing route I get the correct output and every other URL is showing the 404:

• project.com/login - Fine, login page

• project.com/ghdkfgl - 404

This looks clear and seems to be working as expected. So anything I add after the slash opens either an actual existing page or a 404 page.

Unless I put a 'index.php' anywhere in the URL. In this case, Laravel is executing the request for some reason like this:

• project.com/jhdfkds/index.php/login - Opens the login page (the CSS and other resources are gone because of the paths but that's clear).

• project.com/kfhjdsg/index.php/fkdhsg - Opens a 404 (but the CSS and other resources are not loaded too).

I'm sure both of these should open the 404 since there's no such routes in my project.

I also checked for the same behavior on the Laravel documentation website (I assume its built on Laravel).

• http://laravel.com/docs/5.0 - Actual URL

• http://laravel.com/aaa - A nice 404 page

• http://laravel.com/aaa/index.php/docs/5.0 - Laravel documentation page again, same as the first one

What might be causing this? How can this be solved?

Why would Laravel even consider the 'index.php' in the middle of the URL?

Does this have anything to do with the .htaccess file? (I didn't edit it though)

Answer 1

Same issue i was facing in laravel 3 when i was skipping public from url. then i have placed another htaccess file in public folder.

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

Answer 2

The problem is inside the Symfony Request class and how it determines the base URL. Basically it assumes that if you have a request like aaa/index.php that your currently running script (named index.php) is inside the directory aaa takes aaa/index.php as base URL.
Later it will then be stripped from the actual request URI.

I fixed this unwanted behavior with a pull request that is currently under review. I will update this post as soon as it gets merged.