Я установил gitlab на своем личном сервере и использовал этот ответ и этот ответ (вместе с некоторыми данными из this , чтобы он работал с моей установкой apache. Все работает нормально, когда я захожу на gitlab.example.com, я вижу пользовательский интерфейс gitlab, могу создавать учетные записи и т. Д. Однако, когда я проверил URI, на который меня перенаправили, это
https://gitlab.example.com//users/sign_in
(обратите внимание на две косые черты после домена). На самом деле это не проблема, но я хотел бы знать, почему это так и как Я могу это исправить - тем более, что это работает так же хорошо, когда я удаляю одну из косых черт в адресе (так что https://gitlab.example.com/users/sign_in
абсолютно то же самое).
Я На самом деле, я дважды перенаправлялся:
GET https://gitlab.example.com
=> 301 перемещен навсегда
с Расположение: https: //gitlab.example.com /
GET https://gitlab.example.com/
=> 302 Найдено
с Местоположение: https: //gitlab.example.com//users/sign_in
Это мой файл конфигурации apache (`/etc/apache2/sites-enabled/gitlab.conf):
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName gitlab.example.com
ServerSignature Off
ProxyPreserveHost On
ProxyPassMatch ^(/[^/]+\.(html|png|ico|css|txt))$ !
ProxyPass /assets !
<Location />
Order deny,allow
Allow from all
ProxyPassReverse http://127.0.0.1:8080
ProxyPassReverse http://gitlab.example.com
</Location>
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%(REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA]
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
Это проблема с gitlab? Как я могу обойти это?
Примечание: Я абсолютно не уверен, какой модуль вызывает поведение пересылки, если вам нужны другие файлы конфигурации, просто дайте мне знать.
Попробуйте добавить трейлинговую косую черту / к целевому URL ProxyPass, т. е. измените
ProxyPassReverse http://127.0.0.1:8080
на
ProxyPassReverse http://127.0.0.1:8080/
, поскольку вы применяете эти директивы к пути, который также заканчивается трейлинговой косой чертой / (или только косой чертой в данном случае:
), как предупреждает руководство:
Если первый аргумент заканчивается на трейлинг /, то второй аргумент также должен заканчиваться на трейлинг /, и наоборот. В противном случае, результирующие запросы к бэкенду могут пропустить некоторые необходимые слэши и не дать ожидаемого результата.