Potentially Unwanted Behavior when served behind Reverse Proxy
Summary
In my limited understanding...I believe I have found some potentially unwanted behavior when serving GitLab from behind a HTTP(S) reverse proxy. When making a request for a repositories file listing over an http(s) connection proxied by a reverse proxy, some of the GitLab server's response body is generated via the external_url configuration variable in the embedded NGINX server configuration. Because the full URL (including server name) is then written in the response body, a reverse proxy, which typically only rewrites headers, cannot rewrite the URLs in order to proxy the page content.
I am under the impression that the external_url variable is meant to reference the name of the GitLab server itself and not an external proxy, however I believe I can resolve the issue by changing this variable to the name of the reverse proxy and then only accessing the GitLab server through the proxy. I am under the impression that this would cause issues if I wanted to access the GitLab server directly and circumvent the proxy for any reason.
This issue did not appear for me until GitLab-ee 13. GitLab-ee 12 did not appear to have this issue. I upgraded from 12.7 something I believe through to 13.0.6
For more, see this thread on the Community Forums.
Steps to reproduce
Set up GitLab on a dedicated VM with default settings, if asked to configure external_url use the name of the server. Name the server something like gitserver.yourdomain.whatever. Create an internal DNS A record for the server.
Set up HaProxy, NGINX, or any other commonly used HTTP(S) reverse proxy server on a separate dedicated VM, follow best practices for proxying http(s) connections. Create an internal DNS A record for the proxy server and call it something like proxy.yourdomain.wahtever. Create an internal DNS CNAME record for the proxy server called git.yourdomain.whatever and point it to proxy.yourdomain.whatever. You now have a reverse proxy that can live in a DMZ and serve content for multiple different services, including gitlab, both internal to your network and external (with the appropriate firewall rules and port forwards)
Test connecting to the GitLab service via the proxy server. The interface and most functionality should work however file links inside any code repository will be broken.
What is the current bug behavior?
Making direct requests for individual files within your Git repositories should work perfectly, as long as you specify the name of your proxy server, however the links to individual project files and directories within the GitLab web interface will point to whatever the external_url is configured as. This is part of the response body and not due to a response header, as far as I can tell.
What is the expected correct behavior?
The links on every page within the GitLab application should be relative and the server name should be "assumed". I think this would fix the issue but I'm not positive and I'm not sure how much of GitLab relies on the external_url value.