%2f in uri and PATH_INFO vs REQUEST_URI

[basbloemsaat]

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?

[veryrusty]

@basbloemsaat sorry for being tardy with a response - I've got another 10 or so days of work I need to get finished before I can give this further thought and/or a sensible response.

Note that Catalyst has an option to allow using REQUEST_URI (which is off be default), see their docs on its use_request_uri_for_path config option; seems to be pros and cons either way.

Its possible that using a megasplat and joining up the elements may provide a workaround; I need to think/work that through.

If anyone else want to follow up on this, please go for it.

[basbloemsaat]

I agree there seem to be pros and cons either way. Another "solution" could be to note it in the documentation as a limitation or caveat.

The reason I raised an issue is that I encountered this and it took me a lot of time to track it down. Whatever we decide, I aim to make it a smoother experience for other people encountering this.

[Relequestual]

@bigpresh This issue exists in D1 also. Should a seperate issue be created? Although it does seem debatable and potentially breaking for some applications if fixed =/

[cxambs]

I needed to workaround for that :-/ and we are in 2022.