%2f in uri and PATH_INFO vs REQUEST_URI

Dancer2 uses PATH_INFO to match routes (in Core::Route->match Core::Request->dispatch_path is called, which resolves to Plack::Request->path). This has the consquence that resources with a slash (encoded as %2f) are decoded before matching, as Plack decodes this: https://metacpan.org/pod/distribution/PSGI/PSGI/FAQ.pod#Why-is-PATH_INFO-URI-decoded. For other backends this is undefined, or dependent on server configuration (eg. http://httpd.apache.org/docs/2.2/mod/core.html#allowencodedslashes)

ergo: a route defined as

del '/:myvar' => sub {

and a request

DELETE '/test%2fvar'

will not match if using Plack as a backend and may or may not match using other backends.

In my opinion this should not be dependent on the backend; in this example they should match, and param('myvar') should return "test/var".

This can be achieved by using (through the dispathc path interface or another way) REQUEST_URI instead of PATH_INFO in Core::Route->match. This has the disadvantage that URI decoding of params becomes a Dancer2 responsibility.

Thoughts?

Start with Core::Route->match and the Core::Request->dispatch_path path that resolves to Plack::Request->path. Compare the reported DELETE '/test%2fvar' behavior with PATH_INFO and REQUEST_URI, including the backend differences described in the issue. Done should mean the route behavior and param('myvar') result are defined consistently for encoded slashes.