I'm trying to configure my Apache reverse proxy to match URIs accessed by git clients using the HTTP backend, for authentication purposes¹. For this I would like to match HTTP requests on the URI on the proxy and treat them differently. No problem in the latter part, but I have trouble finding a good URI pattern/list to match those requests.
What I've found so far is:
GIT_CURL_VERBOSE=1
). Observed so far:
<base-url>/info/refs?service=git-upload-pack
<base-url>/info/refs?service=git-receive-pack
<base-url>/git-upload-pack
<base-url>/git-receive-pack
Documentation in the Git book on transfer protocols, but this seems incomplete by design:
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.
A suggested Apache configuration in the manpage of git-http-backend.
RewriteCond %{QUERY_STRING} service=git-receive-pack
makes the assumption nothing else is serving on the same VirtualHost, because it would break non-Git resources with this, unless I would add the additional requirement that the URI without the query string matches ~ /info/refs$
.What also worries me with simply listing the above patterns is:
So, ideally, I'd like to be pointed at some piece of documentation/code that shows a complete overview which URIs git http clients may operate on. It may be a simple regular expression - that's what I'm looking for of in the end anyway - as long as it's authorative.
¹ I'm trying to perform SSO login using Apache as authenticating reverse proxy, with different type of authentication for Git over HTTPS vs regular web pages. The app, Gerrit Code Review, serves both pages and Git repositories over a common URL prefix with SSO authentication and auth.trustContainerAuth
enabled, so I can't really match on e.g. ^/git/.*
as suggested on the manpage of git-http-backend
.
The list of paths for both smart and dumb HTTP is in the source code. Note that it does not include query parameters or Content-Types.
Note that there is ongoing work to add SHA-256 support to Git, and consequently anything that now accepts a 40-character hex string will also in the future handle a 64-character hex string.