Hi,

What do you think about this? I have a use case where I need to have a New Router on top of an Old Router, so if the New Router does not find a route for the Request, it gives the opportunity to the Old Router to handle it and try to match a route for it.

To give a bit more context, in the Old Router I check whether the request-handler attribute is already set in which case I delegate to the next handler:

if ($request->getAttribute('request-handler') !== null) {
    return $next->handle($request);
}

I think we should handle these situations where we might have "multiple request handlers finders" (routers).

I'm also thinking about whether It would be a good idea to have some sort of "404 not found" behaviour (set default 404 Response) for the request-handler component if the request-handler attribute was not set in any of the handlers.

Let me know what you think and if it's ok I can update the README.md and do the same for the Aura Router package.

P.D: Now I also have doubts about what should happen with the 405.

Like a Dispatcher instance, a ResponseFactoryInterface instance must be available for this middleware to run. It makes sense for it to be set during construction.

This also enables automatic dependency injecting (“autowiring”) such as available through Auryn, PHP-DI, Symfony, and (probably) many others.

Another perk is that Factory::getResponseFactory gets to run during construction now as well. If it is incapable of finding a factory it can throw there, rather than waiting for FastRoute::process to be called.

I have left the FastRoute::responseFactory method in case people want to change their response factory after the fact. But am tempted to remove it. There isn’t a separate method for changing the dispatcher after construction either.

What do you think?

I’d also appreciate some guidance on how you’d like this documented in the README in case you would consider merging 😃

Currently if the callable is an array the resolver will be called with this array as the id.

Callable arrays with fast route usually look like this:

[\Namespace\To\Controller::class, 'methodName']

I propose adding an extra check and only try to resolve the first element of the array here

WDYT?

How can I make working for example this route? ['GET', '/article/{id}', ['SuperBlog\Controller\ArticleController', 'show']] ?

It works with FastRoute but in middle ore I get this error:

Deprecated: Non-static method SuperBlog\Controller\ArticleController::show() should not be called statically in.

ArticleController constructor has 3 params and I am using php-di and Relay packages.

I could not find a way to access the matched route pattern for a given request or its consequent response. Being able to access to it would be good for observability purposes.

By separating discovery from resolving and invoking, it is possible to apply routing earlier in the middleware process to handle 404s and 405s as quickly as possible, before doing any additional work in other middleware.

This provides a clearer separation of concerns and allows more complex use cases.

Right now the only option for people that do not use PSR-11 containers is to make all of their routes into closures. By allowing direct injection of a callable resolver, anyone will be able to write a resolver that suites their application.

This breaks backwards compatibility by replacing the previous resolver and moving it to container().

Are there any code examples of how to implement the 404 and 405 custom errors? Also are there any examples are how to implement things like 301 redirect responses in connection with the return?

closes https://github.com/middlewares/fast-route/issues/14

Should I send also migration from Travis to GitHub actions? Since Travis is ultra-slow these days and obviously does not have PHP 8.0 ready, GitHub actions are far better nowadays.

I pushed the example of GitHub actions in this repository. If you want, I can prepare the same for the others.

You can look into https://github.com/solcik/fast-route/actions/runs/388555467

This one is ready .)

• github actions
• dependencies fixed
• phpunit updated
• phpstan added

Decode url path before matching routes to work with any path with accent.

Example

• http://localhost:8080/hello/accentu%C3%A9

Which should decoded as:

• http://localhost:8080/hello/accentué

This is also done in Symfony: https://github.com/symfony/symfony/blob/4.2/src/Symfony/Component/Routing/Matcher/UrlMatcher.php#L87

This removes all handler/controller resolving and invoking. By separating discovery from execution, it is possible to apply routing much earlier and send 404s and 405s as soon as possible.

This provides clearer separation of concerns and allows more complex middleware configurations.

Refs #5