processUrlPath rejects smart-HTTP requests when the repo path omits .git

[cniska-oura]

Describe the bug

processUrlPath only accepts request paths that contain .git before the smart-HTTP suffix (regex (.+\.git)(\/.*)?/). Many clients send paths without .git, e.g. /owner/repo/info/refs?service=git-upload-pack. Those requests fail parsing before the plugin chain runs. GitHub accepts both forms.

To Reproduce

Steps to reproduce the behavior:

1. Run @finos/git-proxy@2.0.0 with a repository on the authorised list.
2. Send a smart-HTTP discovery request without .git in the path: GET /owner/repo/info/refs?service=git-upload-pack
3. Send the same request with .git: GET /owner/repo.git/info/refs?service=git-upload-pack
4. See error on step 2: smart-HTTP pkt-line Invalid request received (HTTP 200); git clone fails (could not determine hash algorithm; is this a git repository?). Step 3 succeeds.

Expected behavior

Both path forms parse and reach the normal action/plugin chain. Normalising .git-less paths to a repoPath ending in .git internally is fine.

Screenshots

N/A

Desktop (please complete the following information):

• OS: Linux; macOS
• Browser: N/A (HTTP client / git CLI)
• Version: Node 20+; @finos/git-proxy 2.0.0

Smartphone (please complete the following information):

• Device: N/A
• OS: N/A
• Browser: N/A
• Version: N/A

Additional context

Suggested change inside processUrlPath (after the existing .git match fails):

const SMART_HTTP = /^(.+?)(\/(?:info\/refs|git-upload-pack|git-receive-pack)(?:\?.*)?)$/;

const smartHttp = requestPath.match(SMART_HTTP);
if (smartHttp) {
  return { repoPath: smartHttp[1] + '.git', gitPath: smartHttp[2] };
}

Happy to open a PR if useful.

[kriswest]

Recent versions of git proxy reject URLs without .git appended when they are added - certainly in the UI, I'm less sure about the API (it probably should. Also the below issues/PR added a migration script you can run to fix up a pre-2.0 DB to the 2.0 standard, which includes appending the .git to the end of existing URLs:

• Proposal: Automated MongoDB Migration Script from v1.19.2 to v2.0.0 upgrade #1535
  • feat(migrate): DB tooling for v1.19.2 -> v2.0.0 (URLs + emails + ACL audit) #1543

Does that deal with the concern?

If not we'll have to look again at this, if memory serves there was a reason that the .git was necessary, related to a regex. I'd have to dig into it again to remember why. Probably related to parsing URLs in the proxy - with handling for SCMs other than github.com.

[cniska-oura]

Thanks for the reply.

#1535 / #1543 and rejecting non-.git URLs at config time address how repos are stored in the authorised list. This issue is about inbound smart-HTTP paths on the wire: clients send /owner/repo/info/refs?... without .git, processUrlPath returns null, and the request fails before plugins run. Migration does not change that.

GitHub accepts both path forms. If multi-SCM parsing is why .git is required, a github.com-only fallback on smart-HTTP suffixes (after the existing .git match) would preserve current behaviour for .git-suffixed paths.