Redirect Geo HTTP(s) pulls to different path with missing repo
What does this MR do and why?
Previously, we only redirected pushes to a different path on the primary, however with unified URLs, redirecting pulls to the same path will end in a redirect loop.
This changes the redirect so that pulls get also redirected to a different path, that we always proxy to the primary.
Related to #343538 (closed)
Screenshots or screen recordings
Before:
[..]
20:16:11.725075 http.c:715 => Send header: GET /root/project1.git/info/refs?service=git-upload-pack HTTP/1.1
[..]
20:16:11.884092 http.c:715 <= Recv header: location: http://unified.url/root/project1.git/info/refs?service=git-upload-pack
[..] and loop back
fatal: unable to access 'http://unified.url/root/project1.git/': Maximum (20) redirects followed
After:
20:19:35.725075 http.c:715 => Send header: GET /root/project1.git/info/refs?service=git-upload-pack HTTP/1.1
[..]
20:19:37.043350 http.c:715 <= Recv header: location: http://unified.url/-/push_from_secondary/2/root/project1.git/info/refs?service=git-upload-pack
[..]
remote: Enumerating objects: 6, done.
remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 6
Receiving objects: 100% (6/6), done.
How to set up and validate locally
I couldn't get unified URLs working in the GDK yet, testing this on a 1k GET env on nightly with this patch applied on the secondary, with unified URLs.
- Stop Sidekiq on the Geo secondary
- Create a new project, so that it won't be replicated to the secondary (since Sidekiq is stopped)
- Try to clone the project through HTTP(s), while making sure the unified URL points to the secondary, and run into the redirect loop
- Patch this MR on the secondary, restart puma, clone again and observe it working
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.