Inbetriebnahme des git-Proxys auf dem portablen Stack

Angenommen. Der beschriebene Zustand ist der laufende.

Das Paket wird auf einem portablen Server betrieben: Apache mit PHP als Modul, nicht IIS und nicht FastCGI. Der git-Proxy ist der einzige Teil des Pakets, der nicht über doku.php läuft, sondern über einen eigenen Endpunkt mit PATH_INFO hinter dem Dateinamen. Genau diese beiden Eigenschaften — der eigene Endpunkt und der portable Stack — kollidierten bei der Inbetriebnahme an zwei Stellen.

Das Plugin liefert eine web.config mit. Sie ist reines IIS und auf diesem Stack wirkungslos; ihre drei Anliegen mussten einzeln nachgewiesen oder ersetzt werden.

AcceptPathInfo je Datei statt global. Der portable Apache setzt in server/conf/httpd.conf global AcceptPathInfo off. Damit beantwortet er jede Anfrage der Form …/git.php/code/{projekt}/{repo}/info/refs mit 404, bevor PHP startet — der Proxy sieht die Anfrage nie. Eine .htaccess im Plugin-Verzeichnis schaltet die Option ausschließlich für git.php um:

<Files "git.php">
    AcceptPathInfo On
</Files>

Die globale Vorgabe bleibt unangetastet, weil sie für den Rest des Wikis richtig ist.

Die beiden übrigen Anliegen der web.config waren bereits erfüllt und wurden nachgewiesen statt nachgebaut: mod_deflate ist nicht geladen, es gibt also kein gzip, das einen Packfile zerstören könnte, und LimitRequestBody ist ungesetzt. Weil PHP als Modul läuft, erreicht auch der Authorization-Header PHP ohne Zusatzkonfiguration — unter FastCGI wäre dafür eine eigene Regel nötig gewesen.

curl wurde nachinstalliert. Der Transport zu Azure DevOps und der gesamte REST-Weg laufen über curl; ohne die Erweiterung meldet sich der Konnektor als inaktiv, der Repository-Browser lädt nicht und der Proxy bricht ab. Der portable Server brachte sie nicht mit. Ergänzt wurden ext/php_curl.dll sowie die Laufzeitabhängigkeiten libssh2.dll und nghttp2.dll aus dem offiziellen Paket php-8.2.13-Win32-vs16-x64.zip; extension=curl steht in server/php/php.ini.

Nach der Inbetriebnahme geprüfte Wege. Die Liste ist ein Nachweis, kein Funktionsversprechen:

• Die .htaccess im Plugin-Verzeichnis nicht entfernen. Sie sieht überflüssig aus, weil daneben eine web.config liegt; ohne sie antwortet der Proxy auf diesem Stack mit 404, und der Fehler sieht nicht nach einer Serverkonfiguration aus.
• AcceptPathInfo nicht global einschalten, um dasselbe zu erreichen. Die Option je Datei ist die engere Lösung.
• Bei einem PHP-Update muss curl mitwandern. Die Erweiterung muss zur exakten Server-Variante passen: gleiche Nebenversion, Thread-Safe und dieselbe Compiler-Version. Verlässlicher Test: die php8ts.dll aus dem Paket mit der des Servers per Prüfsumme vergleichen.
• Bei einem Wechsel auf FastCGI ist der Authorization-Header erneut zu prüfen; die heutige Annahme gilt nur für PHP als Modul.
• max_execution_time steht auf 30 Sekunden. Für die geprüften Repository-Größen unkritisch, bei sehr großen Repositorys die nächste Grenze.

• Technische Referenz – Aktionen und Einstiegspunkte
• Konzepte – Mounts, Sichtbarkeits-Tier und Grenzen
• Ein gemountetes Repository klonen – der git-Proxy aus Sicht des Anwenders
• Diagnose: git clone antwortet 404 – das Symptom, das dieser Eintrag erklärt