URL Matcher treats trailing slash as distinct url

[aaronleesmith]

I realize, based on the comments in urlMatcherFactory.js, that a URL with a trailing slash is purposely treated like a distinct url. This functionality differs from Angular's built-in functionality, where a trailing slash causes a redirect to the URL without the slash.

I am opening this issue to ask: is treating the slash as a distinct part of the URL a good idea? It definitely causes problems for users who are used to being able to enter it either way. Does it solve enough problems or add enough to the feature set to warrant performing the strange way it does?

[ksperling]

Trailing "/" isn't inherently special in URLs... "/bla" and "/bla/" just aren't the same URL, just like "/bla" and "/BLA" or "/bla/index.html" aren't. Treating these the same is a legacy behaviour that's come out of mapping of URLs to file system paths when service static files.

I'm also not convinced that users still enter a huge proportion of URLs by hand in this day and age, or at least not without auto-complete assistance from the browser. Any links that the app itself generates should point to the correct canonical version of a URL and not rely on redirect behaviour.

That said, I'm not opposed to adding "trailing slash magic" as an option. However there is more important work to be done in the URL parsing area still (like support for different parameter types and custom encodings, dynamic parameters, etc) that I'd rather not complicate with minor features like this.

[jeme]

I think it is important to separate what is different URLs to the system and to the user. There is a reason why re strive to make meaningful urls from a user perspective... If we look at it as raw as you present it there... we may as well use the urls: "/a", "/b", "/c", "/d" and ones we have enough pages will have urls like: "/69e6c55f712d4028bc2169dd291fecc0"...

But we don't, because having "/users/jeme" makes sense to us when we read it.

And even while much navigation would be done through the system, and therefore we can therefore at large avoid the problem, that doesn't mean it at all makes sense to present the user with different content for the following 3 urls: "/users/jeme", "/users/jeme/", "/Users/jeme"... etc... I would read them all the same and expect them to be the same...

Weather the API should deal with it or not is a different discussion maybe, but saying that "/bla" is a different url than "/bla/" and "/BLA" is subjective to the system, and not the reader/user. Rather than being more objective.

And considering it's not the first time it has come up, as well as angular core supporting it (they also added the ability to match routes and ignore casing now)... So I don't think we can easily dismiss it by being "legacy"... It seems to be very much desired by some still, maybe because they view URLs from a user perspective.

In my own case I added both purely to mimic the behavior for the server, (IIS) which is both case insensitive and ignores those slashes... so id seemed silly that I could query the server with "/data/something", "/data/Something" and "/DATA/something/" and in all cases receive the same data back, but I my page would only work for "#/data/something".

[nelsonpecora]

I disagree with @ksperling's assumptions about users typing in urls, though I agree with his conclusions. Like I noted here, this functionality would be really nice to have (especially for those of us who put urls in our marketing materials), but isn't as important as core features.

[eddiemonge]

https://gist.github.com/eddiemonge/f6a58169c2846731a1eb