I don't get it. When there is no route for the current uri path (ResourceNotFoundException) and the request method was POST, then it throws a MethodNotAllowedException? But we don't know at this point that a GET to the same URI would be allowed, do we?

correct! I've moved the check a few lines below where it belongs

How do we know that GET is actually allowed? If we do a POST /foo on a PUT /foo/ route, it will say method not allowed but GET is allowed? We don't know if GET is allowed at all.

Yes it is: the redirect handles the GET

I guess you need to check if get is in the allowed methods of the route first.

and if not we can mark the request with 307 response in master and here we just continue matching

GETis allowed: it triggers a redirect. There is nothing else to consider on this very path without slash. The verbs allowed on the route apply only when there is a slash.

retry the same request with GET and he could still receive a 404

Why? to my understanding, it would then get a 301/302, because of this very "if" which will be hit again.

@Tobion note that if you're fine with the 404, but not with the 405, I'm OK to remove this line. It's only a minor thing on the HTTP side, and I doubt it will make any real difference in practice.

ping@Tobion let's agree on this and move on :)

If you replace HEAD with GET in$supportsTrailingSlash = $supportsRedirections && (!$methods || in_array('HEAD', $methods)); this works for PhpMatcherDumper. But the logic in RedirectableUrlMatcher is broken. See below.

done

Same here, we don't know if GET is allowed at all.

This cannot work because we don't know if GET for the route is allowed. We would need to make a similar check as in the PhpMatcherDumper likein_array('GET', $route-getMethods()). But we don't have access to the route, so that is difficult to do.
Example:
Route definition: POST /foo/
Request: POST /foo -> throws ResourceNotFoundException, then we check again with slash, i.e. POST /foo/
This works so we return MethodNotAllowedException with allow GET
But GET /foo is not allowed. It will just return a 404 again if someone tries that.

So I don't see how to implement this logic in the RedirectableUrlMatcher. We could just say, RedirectableUrlMatcher does not support that feature. And revert this here but keep the logic in PhpMatcherDumper which most people use anyway.