302 Redirect to incorrectly cased project
I have two projects I'm working on in which the project paths are the same name but with different cases, i.e. example
and Example
. When going to /aribsummer/Example
it redirects me to /aribsummer/example
, making /aribsummer/Example
inaccessible. The issue seems to be related to #1365 (closed) and !1330 (merged).
In order to figure out what was going on, I ran through a few test cases.
Case 1
- Create new project with project path
Example
- Create new project with project path
example
- Navigate to
https://gitlab.com/<username>/example
Actual Result: Redirected to https://gitlab.com/<username>/Example
making https://gitlab.com/<username>/example
inaccessible.
Expected Result: Navigated to https://gitlab.com/<username>/example
.
Case 2
- Create new project with project path
example
- Create new project with project path
Example
- Navigate to
https://gitlab.com/<username>/Example
Actual Result: Redirected to https://gitlab.com/<username>/example
making https://gitlab.com/<username>/Example
inaccessible.
Expected Result: Navigated to https://gitlab.com/<username>/Example
.
Case 3
- Create new project with project path
A
- Create new project with project path
a
- Navigate to
https://gitlab.com/<username>/a
Actual Result: Redirected to https://gitlab.com/<username>/A
making https://gitlab.com/<username>/a
inaccessible.
Expected Result: Navigated to https://gitlab.com/<username>/a
.
Case 4
- Create new project with project path
a
- Create new project with project path
A
- Navigate to
https://gitlab.com/<username>/A
Actual Result: Redirected to https://gitlab.com/<username>/a
making https://gitlab.com/<username>/A
inaccessible.
Expected Result: Navigated to https://gitlab.com/<username>/A
.
From #1365 (closed), "Since group and project paths uniqueness validation is case-insensitive...". This doesn't seem to be the case (https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/models/project.rb#L149).
Since name and path uniqueness are case sensitive, maybe we can do some checks before redirecting to the downcased version of the path, i.e. checking if the requested path exists first. Or maybe redirecting to the downcased version of the path doesn't make sense? Thoughts?
I'd be more than happy to help fix this and put in a MR, just want to see what others are thinking before doing so.