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.

  1. Stop Sidekiq on the Geo secondary
  2. Create a new project, so that it won't be replicated to the secondary (since Sidekiq is stopped)
  3. Try to clone the project through HTTP(s), while making sure the unified URL points to the secondary, and run into the redirect loop
  4. 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.

Merge request reports

Loading