#4831 Canonical URLs
Closed: Won't Fix 3 years ago by ngompa. Opened 3 years ago by xyzzyx.

Problem:

There seems to be quite a lot of views that use 2 versions of the same URL path, with and without trailing slash. For example in pagure/ui/app.py the view_user view has the following routes:

@UI_NS.route("/user/<username>/")
@UI_NS.route("/user/<username>")

This looks very confusing to me, and it also creates 2 different URLs with duplicate content. There are 2 URLs for a repository, 2 for a user, and so forth.

Expected behavior

There should be only 1 canonical URL for a repository, 1 for a user, and so on with all other resources.

Proposed solution

I'd like to suggest the removal of one of the 2 routes (unless of course there's a specific reason to have both) by choosing one of the two as the "canonical" URL.

Additional notes

  • According to the Flask documentation, with "/user/<username>/" Flask will automatically redirect "/user/<username>" to "/user/<username>/".
  • with "/user/<username>", the path "/user/<username>/" will not exist

I'm inclined to suggest we eliminate the route variants without trailing slashes, given the Flask behaviors...

I'm inclined to suggest we eliminate the route variants without trailing slashes, given the Flask behaviors...

+1 for me

I believe the idea is that url with a trailing / are meant to be seen as "folder" while the ones w/o do not have sub-level.

so it would be /issues/ and /issue/123 (or potentially better: /issues/123).

Metadata Update from @ngompa:
- Issue set to the milestone: 5.11

3 years ago

Looking more into this ticket.

The issue only concerns the UI as the API already enforce a certain behavior (either / or not but not both).

  • If we do: @UI_NS.route("/<repo>/") then pagure.io/pagure will redirect to pagure.io/pagure/ (which tbh I'm not 100% fond of)
  • If we do: @UI_NS.route("/<repo>") then pagure.io/pagure will work but pagure.io/pagure/ won't.

We currently support both pagure.io/pagure and pagure.io/pagure/ and checking github and gitlba it looks like they both do too.

So I am a bit wondering if we really want to change something here.

We probably don't in this case. This is a behavior that people tend to expect, and I'd rather not break that expectation.

Metadata Update from @ngompa:
- Issue close_status updated to: Won't Fix
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata