Gitlab always redirects to HTTPS - even with cURL

I’ve got a gitlab backup file from a previous Gitlab-CE v16.4.0 deployment and my users need to retrieve an old repo that was not migrated to a new server. So I built a new server and installed Gitlab-CE v16.4.0. I configured the /etc/gitlab/gitlab.rb with external_url 'http://gitlab.mydomain.com'. Before restoring the database, I’m able to access the UI using root user and it serves all pages over plain HTTP.

However, after restoring the backup, and without changing the external_url, I’m now being redirected to HTTPS. The cURL command on the local machine also gets a 302 to HTTPS:

# grep gitlab.mydomain.com /etc/hosts
10.13.13.211 gitlab.mydomain.com

# curl -I http://gitlab.mydomain.com
HTTP/1.1 302 Found
Server: nginx
Date: Sun, 04 Feb 2024 03:13:16 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache
Content-Security-Policy: 
Location: https://gitlab.mydomain.com
Permissions-Policy: interest-cohort=()
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Gitlab-Meta: {"correlation_id":"01HNS1P7GXDSPHNEDMSMJE0WT0","version":"1"}
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01HNS1P7GXDSPHNEDMSMJE0WT0
X-Runtime: 0.028249
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

I suspect that somewhere in the UI of the restored backup is a setting that I must have enabled at one time on the old server to redirect to HTTPS. How would I disable that setting so that I can get to the repo without having to deploy SSL certificates on a proxy? The server is going to be online for a short period and it’s not the production server anyway.

EDIT: Thought to include output of curl before restore:

# curl -I http://gitlab.mydomain.com
HTTP/1.1 302 Found
Server: nginx
Date: Sun, 04 Feb 2024 01:13:47 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache
Content-Security-Policy:
Location: http://gitlab.mydomain.com/users/sign_in
Permissions-Policy: interest-cohort=()
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Gitlab-Meta: {"correlation_id":"01HNRTVEJQX7E27P55RRM48229","version":"1"}
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01HNRTVEJQX7E27P55RRM48229
X-Runtime: 0.030557
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

OK - so discovered that I can navigate to http://gitlab.mydomain.com/users/sign_in and I get to bypass the redirect.

However, now I get the Gitlab Logo and “Gitlab Community Edition” and just whitespace - no username/password prompt!

Slowly getting there.

EDIT:

The site: Sign-in restrictions | GitLab tells me to go the rails console and type in Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)
However, I get the following error:

# gitlab-rails console
--------------------------------------------------------------------------------
 Ruby:         ruby 3.0.6p216 (2023-03-30 revision 23a532679b) [x86_64-linux]
 GitLab:       16.4.0 (6d091758c4b) FOSS
 GitLab Shell: 14.28.0
 PostgreSQL:   13.11
------------------------------------------------------------[ booted in 13.66s ]
Loading production environment (Rails 7.0.6)
irb(main):001:0> Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)
/opt/gitlab/embedded/lib/ruby/gems/3.0.0/gems/encryptor-3.0.0/lib/encryptor.rb:98:in `final': OpenSSL::Cipher::CipherError

And finally, remembered that I had yet to copy the secrets across. So now I can finally login using username/password.

However, my initial issue is still present - that is, going to HTTP://gitlab.mydomain.com still results in a redirect to HTTPS://gitlab.mydomain.com.

As long as I manually type in (or access a bookmark saved as) http://gitlab.mydomain.com/users/sign_in and login, there are no redirects to HTTPS.

Have I stumbled upon a bug that needs addressing?

EDIT:

The only setting in /etc/gitlab/gitlab.rb is:

# egrep -v '^#|^$' gitlab.rb 
external_url 'http://gitlab.mydomain.com'

One last observation before I depart:

cURL on the server:

# curl -I http://gitlab.mydomain.com/
HTTP/1.1 302 Found
Server: nginx
Date: Sun, 04 Feb 2024 07:04:32 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache
Content-Security-Policy: 
Location: https://gitlab.mydomain.com  <<<<<<<<<<<<<<< Redirected to HTTPS
Permissions-Policy: interest-cohort=()
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Gitlab-Meta: {"correlation_id":"01HNSEXP7CHR004MNJJ4H179AN","version":"1"}
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01HNSEXP7CHR004MNJJ4H179AN
X-Runtime: 0.027609
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

# curl -I http://gitlab.mydomain.com/sdfgasdfg
HTTP/1.1 302 Found
Server: nginx
Date: Sun, 04 Feb 2024 07:04:39 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache
Content-Security-Policy: 
Location: http://gitlab.mydomain.com/users/sign_in  <<<<<<<<<<<<<<< No redirect to HTTPS
Permissions-Policy: interest-cohort=()
Set-Cookie: _gitlab_session=a1a1ddcf956879ffdd2ceceb50280371; path=/; expires=Sun, 04 Feb 2024 09:04:39 GMT; HttpOnly
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Gitlab-Meta: {"correlation_id":"01HNSEXX6J25YF65HPY2T88FW1","version":"1"}
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01HNSEXX6J25YF65HPY2T88FW1
X-Runtime: 0.043312
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

Starting to look and smell like a bug to me…