Messa in servizio del proxy git sullo stack portabile

Accettato. Lo stato qui descritto è quello in esercizio.

Il pacchetto gira su un server portabile: Apache con PHP come modulo, non IIS e non FastCGI. Il proxy git è l'unica parte del pacchetto che non passa per doku.php, bensì per un endpoint proprio, con PATH_INFO dopo il nome del file. Proprio queste due proprietà — l'endpoint separato e lo stack portabile — sono entrate in conflitto in due punti durante la messa in servizio.

Il plugin fornisce un file web.config. È puro IIS e su questo stack non produce alcun effetto; le sue tre esigenze hanno dovuto essere dimostrate o sostituite una per una.

AcceptPathInfo per file anziché globale. L'Apache portabile imposta AcceptPathInfo off per l'intero server nel file server/conf/httpd.conf. Risponde perciò a ogni richiesta nella forma …/git.php/code/{progetto}/{repository}/info/refs con 404 prima che PHP si avvii — il proxy non vede mai la richiesta. Un file .htaccess nella cartella del plugin attiva l'opzione solo per git.php:

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

L'impostazione globale resta intatta, perché per il resto del wiki è quella giusta.

Le altre due esigenze del file web.config erano già soddisfatte e sono state dimostrate anziché ricostruite: il modulo mod_deflate non è caricato, quindi non c'è compressione gzip capace di rovinare un packfile, e LimitRequestBody non è impostato. Poiché PHP gira come modulo, anche l'intestazione Authorization raggiunge PHP senza configurazioni aggiuntive — con FastCGI sarebbe servita una regola apposita.

curl è stato installato in seguito. Il trasporto verso Azure DevOps e l'intero percorso REST passano per esso; senza l'estensione il connettore si dichiara inattivo, il browser dei repository non si carica e il proxy si interrompe. Il server portabile non lo forniva. Sono stati aggiunti il file ext/php_curl.dll e le dipendenze di runtime libssh2.dll e nghttp2.dll dal pacchetto ufficiale php-8.2.13-Win32-vs16-x64.zip; la riga extension=curl è presente in server/php/php.ini.

Percorsi verificati dopo la messa in servizio. L'elenco è una prova, non una promessa di funzionamento:

• Non rimuovete il file .htaccess dalla cartella del plugin. Sembra superfluo perché accanto si trova un web.config; senza di esso il proxy su questo stack risponde 404, e il guasto non ha l'aspetto di un problema di configurazione del server.
• Non attivate AcceptPathInfo a livello globale per ottenere lo stesso risultato. L'opzione per file è la soluzione più stretta.
• Un aggiornamento di PHP deve portarsi dietro curl. L'estensione deve corrispondere esattamente alla build del server: stessa versione minore, stessa sicurezza dei thread e stesso compilatore. Una verifica affidabile è confrontare la somma di controllo del file php8ts.dll del pacchetto con quella sul server.
• In caso di passaggio a FastCGI occorre verificare di nuovo l'intestazione Authorization; l'ipotesi odierna vale solo per PHP come modulo.
• max_execution_time vale 30 secondi. Irrilevante per le dimensioni di repository verificate, il limite successivo per quelli molto grandi.

• Riferimento tecnico – azioni e punti di accesso
• Concetti – mount, livello di visibilità e limiti
• Come clonare un repository montato – il proxy git dal punto di vista dell'utente
• Diagnostica: git clone risponde 404 – il sintomo che questa nota spiega