Error when pushing to renamed repository

[lafriks]

Description

When pushing to/pulling from renamed repository there is error:

git fetch
error: RPC failed; HTTP 307 curl 22 The requested URL returned error: 307
fatal: expected flush after ref listing

Gitea Version

1.21.2

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Binary

Database

PostgreSQL

[lunny]

Did you push to the old name or the new name?

[PsychotherapistSam]

Hi, same issue here: When pushing to the old URL of a repo that has been moved (in my case from a user to an org), I get the same error. Setting the new remote URL works, of course.

[lafriks]

When pushing to the old remote url, also by just renaming without changing owner

[lunny]

What's the expectation? Should it be allowed to redirect to the real repository or should it return the 404?

[chris-08154711]

Same here. Seems like the 1.21.2 update (or previous) broke the redirect functionality for renamed repos or organization or when moving a repo from one orga to another.

Before it was possible to rename/move a repo/orga and still use (fetch, pull, push) the local copy without having to "fix" the remote url. Gitea redirected from the previous remote url to the new location/name automatically.
There was a warning on the console that the operation is executed on a redirected URL.

Please fix! Its a pita to rename an organization with certain number of repos and users without this feature!

[lafriks]

What's the expectation? Should it be allowed to redirect to the real repository or should it return the 404?

Previously it allowed to push to old remote url and it would still work as it was pushed to new repo location

[techknowlogick]

Interesting, it appears as though this is because git doesn't accept redirect headers, and we must've previously accepted pushes to renamed repos with a 200 instead of a 308.

This is also interesting as we allow pushes with or without .git trailing, so there should be similar logic.

[lunny]

I cannot reproduce this on main branch with http clone/pull/push when renaming the repository under the same user and also transfer to another org.

[chris-08154711]

I cannot reproduce this on main branch with http clone/pull/push when renaming the repository under the same user and also transfer to another org.

Steps to reproduce:

1. Clone a repo
2. Rename the repo (or move in another orga) in gitea
3. Check "git remote -v" on your clone - remote points to the original repo url/name
4. Try fetch/pull/push with the "invalid" remote url - not working!
5. The original url is still available in gitea UI but beeing 307 redirected to the renamed repo url

[chris-08154711]

@lunny comment above updated with steps and screenshots (sorry, was in a hurry yesterday and couldn't complete the post)

gitea version: 1.21.1
git client version: git version 2.41.0.windows.3

[newgreenshoot]

Just from attempting to quickly bisect this, the last tagged release where this worked was 1.21.0-rc2, and all subsequent versions can't pull/push from renamed repositories when using the old repository URL.

My team suspects that this PR introduced it: #27875

[lunny]

I cannot reproduce this on main branch with http clone/pull/push when renaming the repository under the same user and also transfer to another org.

Steps to reproduce:

1. Clone a repo

2. Rename the repo (or move in another orga) in gitea

3. Check "git remote -v" on your clone - remote points to the original repo url/name

4. Try fetch/pull/push with the "invalid" remote url - not working!

5. The original url is still available in gitea UI but beeing 307 redirected to the renamed repo url

It works for me on main branch.

[j123b567]

gitea: 1.21.5
git client: 2.44.0 and 2.43.0 on linux
gitea is behind reverse proxy using Apache 2.4.57

Running git clone with GIT_CURL_VERBOSE=1 and GIT_TRACE=1. This is HTTP communication from the trace.

POST /<redacted>/<redacted>.git/git-upload-pack HTTP/1.1
Host: <redacted>
Authorization: Basic <redacted>
User-Agent: git/2.44.0
Accept-Encoding: deflate, gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Accept-Language: cs-CZ, *;q=0.9
Git-Protocol: version=2
Content-Length: 175

HTTP/1.1 307 Temporary Redirect
Date: Tue, 05 Mar 2024 10:24:42 GMT
Server: Apache/2.4.57 (Debian)
Cache-Control: max-age=0, private, must-revalidate, no-transform
Location: /<redacted>/<redacted>/git-upload-pack
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Set-Cookie: i_like_gitea=<redacted>; Path=/; HttpOnly; Secure; SameSite=Lax
Set-Cookie: _csrf=<redacted>; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax

Same error
error: RPC failed; HTTP 307 curl 22 The requested URL returned error: 307

[le-patenteux]

I can confirm the issue. Using Gitea 1.21.7 with docker from the linuxserver.io image.
Since we are a small team, I simply had to reset the git origin on my local clone to the new name, but I had to look around for 30 minutes before I found the issue!
Good luck all

[newgreenshoot]

What sorts of setups are other people using? Is Gitea running behind a reverse proxy? Are you requiring HTTP authentication? I'm starting to wonder if there's some specific configuration detail that's responsible for this, since @lunny can't reproduce it under normal conditions. #27875 certainly seems to be responsible though.

This appears to still affect v1.22.0, and my organization is unable to update past v1.21.0-rc2 due to this.

[netsrotr]

We have an possibly related issue renaming a branch via our gitea v 1.21.4 website. If we are at the "branches" view, and try to rename a branch via "rename" symbol at the right side of the branch in question, we get back an http error 404.

[robertschulze]

We have the same issue in 1.21.10. It appears an upgrade will not solve it, is it correct?

[robertschulze]

What sorts of setups are other people using? Is Gitea running behind a reverse proxy? Are you requiring HTTP authentication? I'm starting to wonder if there's some specific configuration detail that's responsible for this, since @lunny can't reproduce it under normal conditions. #27875 certainly seems to be responsible though.

This appears to still affect v1.22.0, and my organization is unable to update past v1.21.0-rc2 due to this.

Yes, we are running Gitea behind a reverse proxy (Apache 2.4.58).

[netsrotr]

We have an possibly related issue renaming a branch via our gitea v 1.21.4 website. If we are at the "branches" view, and try to rename a branch via "rename" symbol at the right side of the branch in question, we get back an http error 404.

Gitea is running behind a apache proxy.

[le-patenteux]

Gitea behind swag (NGINX), authentication by Gitea itself for me.
I can't say if the issue has returned as we did not rename a repo since the incident in march

[winston0410]

I encountered this issue, after changing my username.

[lunny]

Please confirm with no reverse proxy after you upgrade to 1.22.2 and I still cannot reproduce it in main branch and 1.22.2 .

[GiteaBot]

We close issues that need feedback from the author if there were no new comments for a month. 🍵

[lunny]

@lafriks Can you confirm this is still a problem?

[netsrotr]

Rename branch with v1.22.3 works now--Gesendet mit der GMX Mail AppAm 05.11.24, 06:54 schrieb Lunny Xiao ***@***.***>: @lafriks Can you confirm this is still a problem? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[GalaxySnail]

This is still a problem after we upgraded to 1.22.6. We are running gitea behind caddy.

[newgreenshoot]

Though that config option works around the issue, this is still a regression in Gitea since previous versions (as well as Github and Gitlab) don't require it to be set for Git clients to act on renamed repositories.

Why is it returning 307 instead of 301? At a glance, it seems like Git will always follow a 301 "Moved Permanently" but it won't follow a 302 or 307 by default, hence the need for setting http.followRedirects client-side.

Could this issue be reopened, again?

[lunny]

The status code changed from #18063, maybe we can change it back.

[lafriks]

I think for git client requests it should be changed back

[silverwind]

Why is it returning 307 instead of 301? At a glance, it seems like Git will always follow a 301 "Moved Permanently" but it won't follow a 302 or 307 by default, hence the need for setting http.followRedirects client-side.

Where is this info from? Did you dig it out of git source code? The docs on followRedirects makes no mention of any status codes.

[silverwind]

Digging deeper, the default option seems to map to CURLOPT_FOLLOWLOCATION=0, but alas, curl docs only say that 0 means disabled, e.g. I would assume 0 would not follow any redirects.

[newgreenshoot]

I'm not sure that commit solved it. Old Reddit threads suggested it didn't handle 307s well, but in practice, it seems to treat them the same. Bad hunch on my part, I should've tested it more carefully before publicly guessing.

It's worth stressing that other projects had this issue before after Git stopped following redirects by default, see niemeyer/gopkg#50

Additionally, Git should (with its default configuration!) still be able to fetch a renamed repo:

Git will follow redirects only for the initial request to a remote, but not for subsequent follow-up HTTP requests. Since git uses the redirected URL as the base for the follow-up requests, this is generally sufficient.[1]

I mentioned before that my team bisected this issue to being introduced in #27875. Given that this issue only happens on instances with REQUIRE_SIGNIN_VIEW set, it's surely related to the change introduced in "send 401 first if http requires login"?

[wxiaoguang]

Hmm, yes, it seems that #27875 just copied the code and there is no comment to explain why.

Now the "askAuth" logic just duplicates @lunny

[lunny]

I sent #34032 which is an improvement of #27875 . I don't know whether it will fix this problem.

[wxiaoguang]

I sent #34032 which is an improvement of #27875 . I don't know whether it will fix this problem.

Could you reproduce it on your side and/or add some tests?

[lunny]

I can add a test but I cannot reproduce it in my dev env.

[wxiaoguang]

But it can be reproduced, no idea why you can't .....

Behavior before #27875 (git fetch could work)

2025/03/27 15:48:01 HTTPRequest [I] router: completed GET /test1/68.git/info/refs?service=git-upload-pack for [::1]:57112, 301 Moved Permanently in 9.0ms @ repo/githttp.go:517(repo.GetInfoRefs)
2025/03/27 15:48:01 HTTPRequest [I] router: completed GET /test1/68-renamed/info/refs?service=git-upload-pack for [::1]:57112, 401 Unauthorized in 4.9ms @ repo/githttp.go:517(repo.GetInfoRefs)
2025/03/27 15:48:01 HTTPRequest [I] router: completed GET /test1/68-renamed/info/refs?service=git-upload-pack for [::1]:57112, 200 OK in 102.9ms @ repo/githttp.go:517(repo.GetInfoRefs)
2025/03/27 15:48:01 HTTPRequest [I] router: completed POST /test1/68-renamed/git-upload-pack for [::1]:57112, 200 OK in 71.5ms @ repo/githttp.go:477(repo.ServiceUploadPack)

Behavior after #27875 (git fetch doesn't work)

2025/03/27 15:48:44 HTTPRequest [I] router: completed GET /test1/68.git/info/refs?service=git-upload-pack for [::1]:57231, 401 Unauthorized in 0.5ms @ web/githttp.go:16(web.addOwnerRepoGitHTTPRouters)
2025/03/27 15:48:45 HTTPRequest [I] router: completed GET /test1/68.git/info/refs?service=git-upload-pack for [::1]:57231, 301 Moved Permanently in 103.0ms @ repo/githttp.go:517(repo.GetInfoRefs)
2025/03/27 15:48:45 HTTPRequest [I] router: completed GET /test1/68-renamed/info/refs?service=git-upload-pack for [::1]:57231, 200 OK in 67.6ms @ repo/githttp.go:517(repo.GetInfoRefs)
2025/03/27 15:48:45 HTTPRequest [I] router: completed POST /test1/68.git/git-upload-pack for [::1]:57231, 301 Moved Permanently in 61.2ms @ repo/githttp.go:477(repo.ServiceUploadPack)

---

Your PR #34032 is not right, it still behaves as "Behavior after #27875 (git fetch doesn't work)"

[wxiaoguang]

The correct fix should be like this: Fix git client accessing renamed repo #34034