You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, as a beginner with Dancer2 I caught the below - no idea if it's a bug or a expected feature, but for me it was non-intuitive given 'principle of least surprise'...
Consider this simple helloworld.pl:
use Dancer2;
prefix undef;
get '/' => sub { 'hello' };
get '/foo' => sub { 'world' };
dance;
So it's a subtle and fairly minor change in behavior. I haven't checked the code but assume it's an artifact of basically just smooshing the prefix and the route together - would it be relevant to add special case handling for the top-level '/' route when a prefix is involved?
Thanks,
ken1
The text was updated successfully, but these errors were encountered:
The paths /myprefix and /myprefix/ are not the same. The first, without the slash, usually means a file. The second, with the slash, means a directory.
There are a lot of discussions on whether those should point to the same thing in the SEO world. Take a look at https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.html, for example. (By no means am I an authority, that was the first credible source that came up when googling).
Hi, as a beginner with Dancer2 I caught the below - no idea if it's a bug or a expected feature, but for me it was non-intuitive given 'principle of least surprise'...
Consider this simple helloworld.pl:
Starting this makes browsing to http://localhost:3000 perfectly fine (renders 'hello') as well as http://localhost:3000/foo (renders 'world'). So far so good.
Now consider that I want to use a prefix:
My expectation here was that the only change needed when browsing is adding the prefix to the URL. However, browsing to http://localhost:3000/myprefix now gives me 404 - I need to explicitly add the trailing '/' to make it work again, e.g. http://localhost:3000/myprefix/. However, http://localhost:3000/myprefix/foo works as before.
So it's a subtle and fairly minor change in behavior. I haven't checked the code but assume it's an artifact of basically just smooshing the prefix and the route together - would it be relevant to add special case handling for the top-level '/' route when a prefix is involved?
Thanks,
ken1
The text was updated successfully, but these errors were encountered: