gitlab-ce将https修改为http

由于一些未知的原因（猜想应该是gitlab的证书自动renew)，近期自部署的gitlab-ce出现了证书问题。

索性我们禁用gitlab的https功能，将期恢复为http。后期我们再在部署一个nginx进行数据转发，然后在nginx上起用https并设置证书。这样应该就规避了gitlab的证书错误问题。

配置

gitlab-ce的配置文件位于：/etc/gitlab/gitlab.rb中。而将https变更为http的方法很简单，只需要配置external_url为 http 打头即可。

- external_url 'https://gitlab.yourdomain.com:8888'
+ external_url 'http://gitlab.yourdomain.com:8888'

然后使用执行命令：sudo gitlab-ctl reconfigure使其生效。

配置虽然简单，但测试的时候却屡屡发生问题，导致开始怀疑人生。

测试

使用chrome打开地址：http://gitlab.yourdomain.com:8888，却发现产生了307，转向的地址为：https://gitlab.yourdomain.com:8888，这会使得我们开始怀疑前面的配置是否生效了。

即使开启了chrome或firefox的禁用缓存功能，访问原地址仍然是307。这是由于禁用缓存功能并没有禁用浏览器的redirects，所以如果在浏览器上直接进行测试，则需要先清空浏览器的缓存。

比如我们将地址输入地址栏后，然后打开控制台，接着左键点住刷新按钮：

选择清空缓存并且硬加载(Empty cache and hard reload)，此时便可以禁用chrome的redirects的缓存后完成加载了。

其实除了使用浏览器直接测试外，更靠谱的方法是使用一些脚本，比如curl。curl支持使用-I参数来显示返回的状态码及响应头。

相同的地址，如果curl并没有返回307而浏览器却是307则可以确认是浏览器的缓存问题而不是gitlab的配置问题了。

panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888
HTTP/1.1 302 Found
Server: nginx
Date: Tue, 27 Dec 2022 04:33:50 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: no-cache
Location: http://gitlab.yourdomain.com:8888/users/sign_in
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01GN8XQC4NVMGZ7VA4S5QRRX2E
X-Runtime: 0.029655
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

此时首页返回302，回跳地址为：http://gitlab.yourdomain.com:8888/users/sign_in，继续请求该地址：

panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888/users/sign_in
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Dec 2022 04:35:02 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: max-age=0, private, must-revalidate
Content-Security-Policy: 
Etag: W/"7aefc583df813a9b66e476d0c11736b1"
Link: </assets/application_utilities-f86a7caa76c1a2f00550828a9303a66e38d2f043e5f21c2bade17a6ddafe50ab.css>; rel=preload; as=style; type=text/css,</assets/application-f8ba2470fbf1e30f2ce64d34705b8e6615ac964ea84163c8a6adaaf8a91f9eac.css>; rel=preload; as=style; type=text/css,</assets/highlight/themes/white-14ba9f209d5cc375d065606896b08ef3d4dc7be19e5b5800958b390d7ab2bd40.css>; rel=preload; as=style; type=text/css
Permissions-Policy: interest-cohort=()
Pragma: no-cache
Set-Cookie: _gitlab_session=e3d88869c1f709d08bb1887a9da8fb9f; path=/; expires=Tue, 27 Dec 2022 06:35:02 GMT; HttpOnly
Vary: Accept
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01GN8XSJQC57ANRBDYY8J9P8HF
X-Runtime: 0.068342
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

可见状态码为200，非307。此时便可以请放心的去研究浏览器的缓存问题了。

总结

一直以为浏览器的禁用缓存用禁用所有缓存，没想到redirects却是一直走的缓存。这导致本来一个非常简单，早早就已经解决的问题最终却花费了大概一天的时间。有时候就是这样，一旦陷入了某个知识陷阱，凭着本能爬出来便会显示十分不容易。而我们一旦爬出来，以后再有此类问题时，大脑便会发生积极的信号来告诉你历史上我们曾经陷入过。

所以在教学过程中，依据自己的经验来设置更好的陷阱也是优化教学的一个方向。