fix: 404 when refreshing non-homepage routes

[jinrenjie]

What was changed

Fixed an issue where refreshing a page other than the homepage resulted in a 404 error.
Configured the server to correctly handle frontend routes by redirecting them to the index file.

Why?

The application uses client-side routing. Without proper server configuration, refreshing on non-root routes caused the server to look for physical files and return 404.
This fix ensures all routes are handled by the frontend router as intended.

Checklist

• Closes Refreshing page other than homepage leads to a 404 #287
• Tested
  • Tested manually
  • Unit tests added

[butschster]

Hi @jinrenjie 👋

Sorry for the late reply — too many things piled up, but I finally got a chance to review this handler. Thanks a lot, you did a great job spotting where the issue was and fixing it 👏

I think we should approach this handler a bit differently. Right now, FrontendRequest is designed as the last handler in the chain – it only kicks in when no one else has processed the request. That’s why instead of enumerating all the routes it should serve (like /src/, /assets/, /favicon, etc.), it would be more robust to work from the opposite perspective:

We explicitly skip API routes, assets, and other static resources.

Everything else should be treated as a frontend route and resolved through the SPA entry point.

This way we don’t need to maintain an ever-growing allowlist of frontend pages/URLs. As the application evolves and new pages are added, they’ll just work without changing this handler.

Thanks for the contribution!

Something like

    private function isValidRequest(ServerRequestInterface $request): bool
    {
        $path = $request->getUri()->getPath();

        return $path === '/'
            || \str_starts_with($path, '/src/')
            || \str_starts_with($path, '/assets/')
            || $path === '/favicon/favicon.ico'
            || $path === '/bg.jpg'
            || !\str_starts_with($path, '/api'); // <- add this
    }

and

        if (
            !\str_starts_with($path, '/api')
            && !\str_starts_with($path, '/assets')
            && !\str_contains($path, '/src')
        ) {
            $path = '/index.html';
        }

        $path = \rtrim($this->publicPath, '/') . '/' . \ltrim($path, '/');

Take a look at what I’m suggesting — if you can adjust it this way, that would be awesome. Really appreciate your help on this 🙌

[butschster]

Take a look at the suggestions I left. If you’d like, you can refine or improve them, and then we’ll be ready to merge. After the merge, I’ll cut a release and we can test it together. Thanks a lot for your help! 🙌

[jinrenjie]

@butschster Now I have discovered a new issue. When I refresh the /inspector page, it first enters:

server/app/modules/Inspector/Interfaces/Http/Handler/EventHandler.php

Lines 63 to 81 in da21392

	private function listenEvent(ServerRequestInterface $request): ?EventType
	{
	/** @var EventType|null $event */
	$event = $request->getAttribute('event');
	if ($event?->type === 'inspector') {
	return $event;
	}
	if (
	$request->hasHeader('X-Inspector-Key')
	|| $request->hasHeader('X-Inspector-Version')
	|| \str_ends_with((string) $request->getUri(), 'inspector')
	) {
	return new EventType(type: 'inspector');
	}
	return null;
	}

Causing the request that should have gone to FrontendRequest to be mistakenly recognized as an Inspector Event, which ultimately results in the following error:

[butschster]

@jinrenjie

I think we need to fix this line || \str_ends_with((string) $request->getUri(), 'inspector') (Maybe it might end with inspector, but not start with inspector) :D

[jinrenjie]

$request->hasHeader('X-Inspector-Key')
|| $request->hasHeader('X-Inspector-Version')
|| \str_ends_with((string) $request->getUri(), 'inspector')

@butschster I followed your suggestion and fixed this issue, but I am not sure whether it will have a negative impact on the Inspector SDK.

[butschster]

@jinrenjie Thx a lot!