Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

EdRob's avatar
Level 6

[ SOLVED - Sort of ] Route parameter with filename causes 404

EDIT: After failing to find a fix for this, I've basically given everyone who was using "php -S" a Vagrant + Scotch Box combo to work on instead (I'd use Homestead but we're not at PHP 7 yet)

We are trying to protect some admin assets (CSS, JS etc.) by loading them via a special URL which only works when a user has logged in to their admin panel. To do this, we have created an admin-assets folder in resources, and added this route inside our admin middleware group:

Route::get('admin-assets/{filename}','Admin\AdminController@getProtectedAsset')
        ->where('filename','(.*)');

The function this is calling is as follows:


    public function getProtectedAsset($filename)
    {
        $filePath = base_path().'/resources/admin-assets/'.$filename;

        if (File::exists($filePath)) {
            // get the file info
            $fileInfo = pathinfo($filePath);

            // get the mime type
            $mimeTypes = new \Mimey\MimeTypes;
            $mimeType = $mimeTypes->getMimeType($fileInfo['extension']);

            // stream it to the browser
            return response()->download($filePath, null, [
                'Content-Type' => $mimeType,
            ], null);
        } else {
            abort(404);
        }
    }

On my development environment - PHP 5.6, Apache etc. this works OK. If, however, as some of our developers are doing, you try to serve this using php -S localhost:8000 -t public/ - the admin assets URLs 404 IF they contain a dot. I modified the controller function to return the $filename instead of serving the file. If, when this is in place, we request "/admin-assets/logos/logo" for example, it returns this to the screen. "/admin-assets/logos/logo.png" just goes straight to a 404 - not the Laravel exception version, just the server default.

How do I allow a filename / dot in my route parameter in a way that will work in all scenarios? We don't envisage this code being deployed via php -S, but it is being developed this way so I'm keen to try and correct it.

0 likes
1 reply

Please or to participate in this conversation.