There is a PR adding this to sinatra with sinatra/sinatra#1273, but didn't get it to work yet using

set :strict_paths, false

see #22

@KrauseFx @taquitos most web services may do this but if it isn't with a 301 redirect it's creating duplicate content as they are indeed both two separate resources. That's the R and the I in URI. They MUST be unique. (Even if you redirect). If they are not must redirect or use <link rel=canonical...>.

Just because we are doing things doesn't make them sound. To be clear even Roy Fielding said Rails didn't implement REST properly and spent months in endless debates with the man. But if you asked Rails at that time it would have been said they WERE RESTful. Technically speaking until browsers support DELETE,PUT,PATCH there's no framework really restful. But I digress. /foo and /foo/ are two different resources. Hence the need to redirect. In this test SHOULD respect both resources and perhaps perform a redirect. An additional can of worms is opened re: non-safe methods and legacy browsers from my experience. YMMV.

An example to think about is say you have a page on foo/bar and a page on /foo/bar/ if you link to baz.html from the respective pages and navigate in the browser where do you think the URL will resolve to in BOTH cases?

Perfect example of although web servers may implement anti-patterns the web platform may implement otherwise. I've had to solve many a bug in open source from the example above. I also realize Sinatra may be shielded from this converntion with situations like static files always being served from root and url path helpers. At minimum would like to drive home the difference between the resources. Web servers may not consider them to be different. Developers may not want them to be different. The web works otherwise. The entire URI spec's merge algorithm 100% depends on the answer to "What is the last slash in the base path". Within the web platform all browsers implementevery single HTMLElement having a dependency on Node.baseURI to resolve relative paths (e.g. <img src=...>. /a/ and /a will return two different results when the algo runs in the browser.

/cc @tmornini @brandondees

In fact this practice is so pervasive, that for the vast majority of users, a resource URI with or without a trailing slash is treated as a synonym. They are considered two URIs that point to the same resource, using either one is fine. However this understanding is not quite correct...

https://cdivilly.wordpress.com/2014/03/11/why-trailing-slashes-on-uris-are-important/

That's super interesting, thanks for the comment and letting us know @snuggs 👍

As a developer, it's common to modify the URL directly - and as a result often end up with a trailing /.

While not considering this might be 100% correct and according to the specifications, I don't see a reason why we should distinguish, considering that we'll never show different content depending on if there is a trailing / or not

@KrauseFx thanks man! Just some war stories. FWIW.

it's not about different content. It's more about unloading developer footguns. INDEED there are many apps where people use relative urls. Some even merely render html from Sinatra which isn't a bad thing. But if one of those links somehow links to /users and the view links to cat.jpg it won't come from the /users folder. Again I will state Sinatra perhaps is shielded from this by the convention of serving static from /public or wherever. But this is more a discussion of how the web was intended to work at large, and where devs chose ergonomics over UI/UX (and URLs are definitely paramount to UX). Now i'm as lazy as any other developer. But must admit we do load personal footguns up from time to time. "The next generation will deal with it. I need to 🚢 " seems to be our mantra. Still doesn't mean it's right.

To be clear i'm not suggesting anything I just know with working on the platform specs that devs may run the code. But forget that the people run the URIs. Someone bookmarks a link to /users (Perhaps they typed it in and got lazy at the end.) and another links to /users/. True Sinatra may satisfy both and devs are happy. Kill two birds with one stone. However, if Sinatra is doing the trimming behind the scenes now the dev is FORCED to use <link rel=canonical href=/users/> in their code or Google will actually downvote that resource if publicly indexable. We often don't find out until the SEO strategist on the team comes barking at our desk. That's if we still work there. And why she is pissed is because she can't do her job as well as she thought.

Not bringing up for-instances. This actually happened to me.

#SadButTrue

What do you think we should do? I'm not suggesting anything as you influence direction more than I do. I just stumbled across this searching for what is the right 405 for resources for our web components project and "Resource Variants".

At minimum if a redirect is not done perhaps documentation of sorts respectively. And of course I wouldn't suggest something I'm not willing to contribute to myself. I'd just be a curmudgeon then. Open source has enough of this already. :-) Truth be told I'm just as curious as to your thoughts @KrauseFx as my own. This is collaboration yanno. :-)

Happy Friday!

@snuggs said:

until browsers support

I think you mean:

until HTML supports

😄

Indeed @tmornini ... indeed!

The link example should also have been cat.**gif** not cat.**jpg** in retrospect. 😄

@snuggs said:

The link example should also have been cat.gif

¿Por que?