git 客户端操作的 HTTP URI 是否有特定的正则表达式？

Is there a specific regular expression of HTTP URIs a git client operates on?

我正在尝试配置我的 Apache 反向代理以匹配 git 客户端使用 HTTP 后端访问的 URI，以进行身份验证¹。为此，我想在代理的 URI 上匹配 HTTP 请求并区别对待它们。后半部分没有问题，但我很难找到一个好的 URI pattern/list 来匹配这些请求。

目前我发现的是：

试验了日志服务器端（访问日志）和客户端（GIT_CURL_VERBOSE=1）。目前观察到：
- GETs <base-url>/info/refs?service=git-upload-pack
  （ls-remote，或 fetch/clone 的初步）
- GETs on <base-url>/info/refs?service=git-receive-pack
  （git 推送的初步）
- POST 到 <base-url>/git-upload-pack
  （git 获取）
- POST 到 <base-url>/git-receive-pack
  （git 推送）
Documentation in the Git book on transfer protocols，但这在设计上似乎不完整：

This section contains a very basic overview of the transfer protocols. The protocol includes many other features, such as multi_ack or side-band capabilities, but covering them is outside the scope of this book.
the manpage of git-http-backend 中建议的 Apache 配置。
- 它假定您在单独的前缀上提供 git 个存储库，但情况并非总是如此（请参阅我的脚注）。
- 像 RewriteCond %{QUERY_STRING} service=git-receive-pack 这样的部分假设没有其他东西在同一个 VirtualHost 上服务，因为它会破坏非 Git 资源，除非我添加额外的要求，即 URI没有查询字符串匹配 ~ /info/refs$.
- 虽然它可能仍然是最新的，但似乎有点过时，因为它仍在显示授权的 Apache 2.2 配置示例。这让我想知道这是否适当更新并适合可靠的来源。

简单列出上述模式也让我担心的是：

也许有些客户的操作方式不同，例如'dumb protocol' 或 'smart protocol v2'?
Git 协议 2 是否会改变一些事情？
我真的找不到关于协议 HTTP 部分 的规范。我可以在协议的 Git 级别上找到很多内容，但从反向代理的角度来看，这不是我感兴趣的内容。
因此，我可能会破坏用户的东西，由于代理上的模糊 URI 匹配，这很难调试...

所以，理想情况下，我想指出一些 documentation/code 的内容，它显示了一个完整的概述，哪些 URI git http 客户端可能操作。它可能是一个简单的正则表达式 - 这就是我最终要寻找的 - 只要它是权威的。

^{¹ 我正在尝试使用 Apache 作为身份验证反向代理执行 SSO 登录，通过 HTTPS 与常规网页使用不同类型的身份验证 Git。该应用程序 Gerrit Code Review 通过具有 SSO 身份验证和启用 auth.trustContainerAuth 的公共 URL 前缀为页面和 Git 存储库提供服务，因此我无法真正匹配例如^/git/.* 按照 git-http-backend.}

联机帮助页中的建议

智能和哑 HTTP 的路径列表在 the source code 中。请注意，它不包括查询参数或内容类型。

请注意，为 Git 添加 SHA-256 支持的工作正在进行中，因此现在接受 40 个字符的十六进制字符串的任何内容将来也将处理 64 个字符的十六进制字符串。

git 客户端操作的 HTTP URI 是否有特定的正则表达式？

Is there a specific regular expression of HTTP URIs a git client operates on?

git

reverse-proxy

git-http-backend