Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trailing slash in resource routes doesn't work #204

Closed
MiguelMadero opened this issue Oct 3, 2012 · 10 comments
Closed

Trailing slash in resource routes doesn't work #204

MiguelMadero opened this issue Oct 3, 2012 · 10 comments

Comments

@MiguelMadero
Copy link
Contributor

"host/controller/" doesn't work as "host/controller"

@kieran suggested (here) to remove the trailing slash before it hits the router.

@mde
Copy link
Contributor

mde commented Oct 3, 2012

Oh, I had thought this was fixed, but what I fixed was double-slashes.

mde pushed a commit that referenced this issue Oct 3, 2012
@mde
Copy link
Contributor

mde commented Oct 3, 2012

Fixed in c2e664a -- will strip the slash when trying to match a route, but if a route isn't found, will first check if the path is a directory, and look for a an index file. (Some people have the idea that the path "foo/" implies a directory.) Eventually I guess the name of the index file could be configurable.

@mde mde closed this as completed Oct 3, 2012
@dmidz
Copy link

dmidz commented Dec 1, 2013

hello, I installed a fresh geddy but it seems the trailing slash isn't working :
router.get('/myDir/').to('myDir.index');
http://localhost:4000/myDir/ > 404 error : /myDir not found
it doesn't catch the dir (like the root), is there any option or else I miss ?
I don't see the point removing the trailing slash...it would be possible to have a main page accessed with "/myDir" and also a content category accessed with "/myDir/" which points to the index of this dir.

@mde
Copy link
Contributor

mde commented Dec 3, 2013

While stripping the trailing slash might not actually be the best idea, I feel pretty strongly that having my_dir and my_dir/ be two different resources is a bad idea from a practical standpoint. Correct behavior with respect to the trailing slash isn't spelled out in any RFC from what I've seen, but RFC 3986 only mentions it in the Equivalence section as an example of two URLs that are likely to be the same: http://tools.ietf.org/html/rfc3986#section-6.2.4

Other online resources advocate always including the trailing slash, and assuming that anything without an extension is a directory. That seems like advice that might be a little dated in the age of Web apps -- an URL simply represents a resource in the app, and doesn't necessarily map to anything on the filesystem.

@dmidz
Copy link

dmidz commented Dec 3, 2013

I totally agree with you that having two different ressources having the same name, with and without trailing slash, is ambiguous, notably for crawlers, and not essential really, and uri are just resources identifiers that not necesserily reflect any filesystem, so forget my last sentence saying "it would be possible...".
But I agree also that strippring trailing slash is quite hard, sure it is not vital, it is just because I use to use trailing slash when it is somewhat a content category, assuming there will subpage :

  • mainpageA
  • mainPageB
  • myCategory/ -> if other "sub" resources have this url prefix, I prefer using a trailing slash
  • myCategory/subcontentA
  • myCategory/subcontentB
    but well as you said it is much a question of preference...but this little detail - modifying a perfectly valid url - cooled me a bit (sorry for my english), I don't see the benefits for your app. The root of any website is a trailing slash ;-)

@mde
Copy link
Contributor

mde commented Dec 3, 2013

I agree, modifying the resource to strip the slash might not be the best
approach. I can understand how it might leave you a bit cold. (I think
that's the English idiom closest to your meaning.) The benefit is in
handling cases where users forget to add a slash, or needlessly add a
slash. It's not reasonable to expect end-users to specify this correctly
and consistently. I wouldn't be opposed to a different solution that
accomplishes this same thing. If we had something better, we might not have
to special-case the root path, which is what we do now.

Right now we normalize the incoming URL -- perhaps we could also normalize
the route definition as well?

On Tue, Dec 3, 2013 at 3:09 PM, David MARTIN notifications@github.comwrote:

I totally agree with you that having two different ressources having the
same name, with and without trailing slash, is ambiguous, notably for
crawlers, and not essential really, and uri are just resources identifiers
that not necesserily reflect any filesystem, so forget my last sentence
saying "it would be possible...".
But I agree also that strippring trailing slash is quite hard, sure it is
not vital, it is just because I use to use trailing slash when it is
somewhat a content category, assuming there will subpage :

  • mainpageA
  • mainPageB
  • myCategory/ -> if other "sub" resources have this url prefix, I
    prefer using a trailing slash
  • myCategory/subcontentA
  • myCategory/subcontentB but well as you said it is much a question of
    preference...but this little detail - modifying a perfectly valid url -
    cooled me a bit (sorry for my english), I don't see the benefits for your
    app. The root of any website is a trailing slash ;-)


Reply to this email directly or view it on GitHubhttps://github.com//issues/204#issuecomment-29761560
.

@dmidz
Copy link

dmidz commented Dec 4, 2013

Maybe yes, what do you mean by normalize route ? but at least it can alerted that trailing slash are not supported when declaring routes.
In fact I wrote some router in PHP, and I used to have a view file structure that match the url structure because it is very comfortable for mind :
views/
-- _layout.ext
-- _somepartial.ext
-- index.ext
-- somepage.ext
-- somedir/
---- index.ext
---- subpage.ext

I had some little convention :

  • each view can respond to a corresponding request same path (without extension or with anyone) : /somepage -> /views/somepage.ext
  • unless its filename begins by _ which is reserved for special such layout or partial templates, so request with filename begining by _ gives a 404, they can't be directly requested. another way is to have a special subdir or sibling dir for these special template files
  • if url ends with a slash, index is appended to retrieve the view file

This explains why I like trailing slash. So it can work without controller if wished, for say "static" content, then I also set some routes but only for views needing operations / controller.

@mde
Copy link
Contributor

mde commented Dec 5, 2013

You're absolutely right -- what we have now is clearly a bug, because it allows you to define a route that looks legitimate, but will never match anything. At bare minimum we should throw some sort of error in this case.

I believe I understand all the points in your conventions, although Geddy doesn't follow the underscore convention for partials, since we don't yet make any of them available for request directly. I've always found it weird that Rails would name partials with a leading underscore, but you leave out the underscore when rendering with the partial call.

@mde
Copy link
Contributor

mde commented Dec 5, 2013

I've opened an Issue for this problem with the trailing slash in routes: #508

@dmidz
Copy link

dmidz commented Dec 5, 2013

cool ! well maybe "bug" is a bit high but yes some warning would be nice ;-)

Anyways Geddy is cool, particulary the data bridge/interface and sessions, and server javascript just rocks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants