| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | Add latest changes from gitlab-org/gitlab@master | GitLab Bot | 2020-01-24 | 1 | -107/+0 |
| | | |||||
| * | Add latest changes from gitlab-org/gitlab@master | GitLab Bot | 2020-01-10 | 1 | -0/+10 |
| | | |||||
| * | Add latest changes from gitlab-org/gitlab@master | GitLab Bot | 2020-01-06 | 1 | -0/+24 |
| | | |||||
| * | Add latest changes from gitlab-org/gitlab@master | GitLab Bot | 2019-12-27 | 1 | -8/+30 |
| | | |||||
| * | Add latest changes from gitlab-org/gitlab@master | GitLab Bot | 2019-10-08 | 1 | -0/+25 |
| | | |||||
| * | Allow CI to clone public projects when HTTP protocol is disabled | Drew Blessing | 2019-08-14 | 1 | -0/+11 |
| | | | | | | | | | | | | | | | GitLab has a mechanism that allows CI to clone repositories via HTTP even when the HTTP protocol is disabled. This works as expected when a project is private or internal. However, when a project is public CI gets an error message that HTTP is not allowed. This happens because Git only sends auth in a subsequent request after a 401 is returned first. For public projects, GitLab grabs onto that unauthenticated request and sends it through since it recognizes that Guests are ordinarily allowed to access the repository. Later on this leads to a 403 since HTTP protocol is disabled. Fix this by only continuing with unauthenticated requests when HTTP is allowed. | ||||
| * | Reject HEAD requests to info/refs endpoint | Stan Hu | 2019-03-19 | 1 | -0/+15 |
| In production, we see high error rates due to clients attempting to use the dumb Git HTTP protocol with HEAD /foo/bar.git/info/refs endpoint. This isn't supported and causes Error 500s because Workhorse doesn't send along its secret because it's not proxying this request. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54579 | |||||
 |
index : delta/gitlab/gitlab-ce.git | |
| gitlab.com: gitlab-org/gitlab-ce.git |
| summaryrefslogtreecommitdiff |