Error 404 on branches with forward slashes

How to Use GitLab
,
1

Create Branches with forward slashes

I recently upgraded from Gitlab-CE version 14 to 17, was running some tests and came upon this issue.

If you use the command line from VSCode or PowerShell to create a new branch with slashes on the name, it will return error 404 when you try to access the new branch.

image
image783×518 16.7 KB

However, when you run git branch -a or git check-ref-format --branch feature/NewFeature or git rev-parse --symbolic-full-name HEAD everything seems to be OK

When you create a branch manually, using the Web UI, it works correctly

image

Steps to reproduce

  1. Install Gitlab CE 17.1.1 on RHEL 9 (yum install gitlab-ce)
  2. Log in with default user/password
  3. Create a public project manually on the default user namespace
  4. Clone the project using VSCode on a Windows Laptop
  5. Create a new branch with git checkout -b feature/NewFeature
  6. Publish the new branch and try to access from the Gitlab Page
  7. It will return Error 404
  8. Create a new Branch using the Web UI (http://mygitlab.com/myUser/my-new-test-project/-/branches/new)
  9. It will work, even if the branch has forward slash (‘/’) on the name is created using the Web UI

Linux

The same happened when used git from command line on the Linux that runs the Gitlab Instance using git checkout -b feature/MyLinuxFeature and git push --set-upstream origin feature/MyLinuxFeature. It creates a branch, but returns Error 404 when you try to access from the Web UI

Test

VSCode

When VSCode is used, by choosing the Create New Branch option:

image
image809×155 5.28 KB

The same problem happens, the branch is created, but Web UI returns error 404

TestVSCode

Another Issue

Another issue is if the name of the branch starts with Capital Letter, example: ‘Feature/NewTest’. When you commit and publish using the VSCode GUI, it will create a branch named ‘feature/NewTest’ and not the Capital Letter and a merge request will not find it. A solution is to use command lines and not the VSCode GUI.

Configuration

Public Project with a fresh Gitlab Install on a RHEL 9 OS

Versions

Please select whether options apply, and add the version information.

Versions

image
image419×506 18.7 KB

Temp Solution

Create branches on the Web UI and checkout from VSCode GUI, using the command lines

Edit:

Our current temp solution is to run Docker on RHEL, since Gitlab is not working properly when using RHEL OS for Enterprise. And Docker that runs under Ubuntu, running on a RHEL system, is working properly…

2

I got the exact same problem on gitlab-ce 17.1.0, branch names containing forward slashes (e.g hotfix/one) will show 404 when created outside Gitlab WebUI. When creating the branch on the WebUI (saying hotfix/two) the previously created branches will now display properly.

1 Like
3

It seems that this bug isn’t present in 17.0.3-ce.0, the downgrade from 17.1.0 went seamlessly. I hope devs will read this and it’ll get fixed on next release.

4

Hi,

Nice catch. However, it would be the best if you create an issue directly on GitLab: Issues · GitLab.org / GitLab · GitLab - then it can get attention and get prioritized, since it’s a regression.

1 Like
5

Devs don’t tend to read forum posts, they concentrate on the opened issues and priorities there. You would need to report it as @paula.kokic suggested - it’s the only fastest way of getting that achieved. Waiting for a Dev to come here and read it would be like watching paint dry - would take quite a while :slight_smile:

1 Like
6

Opened an issue on gitlab’s gitlab, here is the link : Using forward slahes in branch names causes 404 (#471995) · Issues · GitLab.org / GitLab · GitLab

3 Likes
7

I made a fresh install on RHEL 9, on versions 17.0.3 and 17.0.4, on both CE and EE, and the problem still exists.

What is your OS and the output of the command gitlab-rake gitlab:env:info?

Mine on EE version is:

System information
System:
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   3.1.5p253
Gem Version:    3.5.9
Bundler Version:2.5.9
Rake Version:   13.0.6
Redis Version:  7.0.15
Sidekiq Version:7.1.6
Go Version:     unknown

GitLab information
Version:        17.0.3-ee
Revision:       bb522e4e0a7
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     14.11
URL:            http://myIPAddress
HTTP Clone URL: http://myIPAddress/some-group/some-project.git
SSH Clone URL:  git@myIPAddress:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:        14.35.0
Repository storages:
- default:      unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      17.0.3
- default Git Version:  2.44.2.gl1

It seems some sidekiq problem, because when a new branch is created on the Web UI or a commit is pushed, the error 404 problem is solved and the branch is acessible on the Web UI

8

I pushed the 17.0.4 to prod this morning hoping to resolve the bug, unfortunately it is still there and i dont know why. The docker image used is the same as the test environement (17.0.4-ce.0) which is working like a charm …

Here’s the output of gitlab-rake gitlab:env:info :

System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   3.1.5p253
Gem Version:    3.5.9
Bundler Version:2.5.9
Rake Version:   13.0.6
Redis Version:  7.0.15
Sidekiq Version:7.1.6
Go Version:     unknown

GitLab information
Version:        17.0.4
Revision:       ff4ed932b61
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     14.11
URL:            https://gitlab-test.redacted.lan
HTTP Clone URL: https://gitlab-test.redacted.lan/some-group/some-project.git
SSH Clone URL:  git@gitlab-test.redacted.lan:some-group/some-project.git
Using LDAP:     yes
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:        14.35.0
Repository storages:
- default:      unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      17.0.4
- default Git Version:  2.44.2.gl1
9

Using Docker on RHEL everything works fine, oddly the RHEL server doesn’t work, but the Docker that runs on this server worked.

Those are the infos from the Docker version used:


System information
System:
Current User:   git
Using RVM:      no
Ruby Version:   3.1.5p253
Gem Version:    3.5.9
Bundler Version:2.5.9
Rake Version:   13.0.6
Redis Version:  7.0.15
Sidekiq Version:7.1.6
Go Version:     unknown

GitLab information
Version:        17.0.3
Revision:       3b2998451b0
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     PostgreSQL
DB Version:     14.11
URL:            http://myIP
HTTP Clone URL: http://myIP/some-group/some-project.git
SSH Clone URL:  git@myIP:some-group/some-project.git
Using LDAP:     no
Using Omniauth: yes
Omniauth Providers:

GitLab Shell
Version:        14.35.0
Repository storages:
- default:      unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version:      17.0.3
- default Git Version:  2.44.2.gl1

There is no difference to the one installed on RHEL, the only difference is Proxy: no on RHEL.
Trying to figure if it affects.

Had other issues with Merge Requests not updating or notifying updates, now fixed on docker…

Edit: The docker runs Ubuntu, that is the reason that everything worked fine.

PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
10

Docker version 17.1.2 has issues and as you said, 17.0.x is working…

In my opinion, to break on a controlled environment such as docker and not work properly is a critical bug.

11

Updating the issue, it seems to be a cache problem

Duplicate: