arg_separator.input in PHP: configurazione e uso corretto

Introduzione

arg_separator.input è una direttiva di PHP che definisce quali separatori devono essere riconosciuti quando il motore interpreta la query string di un URL. In pratica, decide con quali caratteri PHP deve dividere i parametri passati in GET, ad esempio nella parte finale di un indirizzo come ?a=1&b=2. È una di quelle impostazioni che sembra marginale, ma in ambienti reali può fare la differenza tra un’applicazione che legge correttamente i parametri e una che “perde” valori in modo silenzioso.

Il punto chiave è semplice: arg_separator.input non genera URL, ma li legge. Se il tuo sito, un plugin WordPress, uno script legacy o un’applicazione custom usa separatori non standard, questa direttiva può determinare se i parametri vengono interpretati oppure no.

Cosa fa davvero arg_separator.input

Quando PHP riceve una richiesta con query string, per esempio:

/pagina.php?foo=1&bar=2

analizza i parametri separandoli secondo i caratteri definiti in arg_separator.input. Il valore predefinito, nella maggior parte degli ambienti, include & e spesso anche ;. Questo significa che PHP può accettare entrambe le forme:

?foo=1&bar=2

oppure:

?foo=1;bar=2

Non tutti i server, però, sono configurati allo stesso modo. Alcuni hosting condivisi, ambienti hardenizzati o configurazioni personalizzate possono restringere i separatori accettati, con effetti visibili solo in casi specifici: link vecchi, integrazioni esterne, URL firmati, sistemi di tracking, applicazioni legacy o script sviluppati anni fa.

Differenza tra arg_separator.input e arg_separator.output

Qui nasce spesso la confusione. Le due direttive hanno ruoli diversi:

• arg_separator.input: stabilisce quali separatori PHP accetta in ingresso quando legge la query string.
• arg_separator.output: stabilisce quale separatore PHP usa quando genera query string, ad esempio tramite funzioni o output automatici.

In altre parole, una riguarda la lettura, l’altra la scrittura. Se modifichi solo arg_separator.output, potresti cambiare il modo in cui PHP costruisce gli URL, ma non il modo in cui li interpreta. Se modifichi solo arg_separator.input, cambi invece il comportamento di parsing dei parametri in ingresso.

Questa distinzione è fondamentale in troubleshooting: un sito può generare URL corretti ma non leggere bene quelli ricevuti da terze parti, oppure viceversa.

Valori possibili e comportamento

La direttiva accetta una stringa di uno o più caratteri. I casi più comuni sono:

• & per accettare solo il separatore standard delle query string moderne.
• &; per accettare sia & sia ;.
• Configurazioni più restrittive o personalizzate, in base a esigenze particolari dell’ambiente.

In un contesto standard web, & è la scelta più coerente. Il separatore ; è una compatibilità storica che può servire in scenari legacy, ma in molti sistemi moderni è preferibile ridurre le variabili e usare solo il formato più comune.

Attenzione però a non confondere il formato HTML con quello dell’URL: dentro una pagina HTML, il carattere & va spesso codificato come & per essere valido nel markup. Questo non significa che il browser lo invii come & nella query string: il browser lo normalizza. PHP, invece, riceve il risultato finale della richiesta.

Quando serve modificarlo

In molti ambienti non serve toccarlo affatto. La modifica ha senso solo se hai un motivo preciso e verificabile. I casi più comuni sono:

• compatibilità con vecchi script che usano ; nei parametri;
• integrazioni con URL generati da sistemi esterni non allineati allo standard atteso;
• migrazione di applicazioni legacy che smettono di leggere correttamente i parametri;
• ambienti con policy di sicurezza o normalizzazione URL particolari.

Se non hai un problema reale, lascia il default del tuo sistema. Ogni deviazione dal comportamento standard va giustificata, testata e documentata.

Come verificare il valore attuale

Il modo più rapido è usare phpinfo() oppure una verifica da CLI. Se hai accesso al server, puoi controllare il valore effettivo con:

php -i | grep -i arg_separator.input

In alternativa, da una pagina PHP temporanea puoi stampare il valore con:

<?php phpinfo();

Il risultato atteso è vedere la direttiva con il valore effettivo applicato dal SAPI in uso. Ricorda che il valore può cambiare tra CLI, PHP-FPM, Apache module e pool diversi: non dare per scontato che la CLI e il web server usino la stessa configurazione.

Se lavori in un pannello come cPanel, Plesk o FastPanel, il controllo va fatto idealmente nel contesto del sito interessato, non solo nel terminale generale. In hosting multiutenza, la differenza tra configurazione globale e locale può essere decisiva.

Dove si configura

La posizione dipende dalla distribuzione e dal tipo di installazione PHP. Le opzioni più comuni sono:

• php.ini globale o della singola versione PHP;
• configurazione del pool PHP-FPM;
• file .user.ini per directory o vhost, se consentito;
• impostazioni del pannello hosting, quando disponibili.

Su sistemi Debian e Ubuntu il file può trovarsi in percorsi diversi a seconda della versione, ad esempio sotto /etc/php/<versione>/fpm/php.ini o /etc/php/<versione>/apache2/php.ini. Su AlmaLinux, Rocky o CentOS spesso la gestione passa da percorsi tipo /etc/php.ini o file di pool PHP-FPM. La regola pratica è sempre la stessa: verifica quale PHP sta servendo il sito e modifica solo il file effettivamente usato da quel servizio.

Configurazione sicura e metodo consigliato

Se devi cambiare arg_separator.input, procedi in modo reversibile. Prima fai un backup del file interessato, poi modifica una sola direttiva, poi verifica il comportamento. Questo riduce il rischio di introdurre regressioni in aree non correlate.

Un esempio di configurazione nel file php.ini può essere:

arg_separator.input = "&"

Se vuoi mantenere compatibilità con vecchi URL che usano anche il punto e virgola, puoi usare:

arg_separator.input = "&;"

La scelta più prudente in ambienti moderni è spesso partire da & e allargare solo se hai un caso d’uso reale che richiede ;. In questo modo riduci ambiguità e mantieni il comportamento più prevedibile.

Esempio pratico di effetto

Supponiamo di avere uno script che riceve questi URL:

/test.php?x=10&y=20

e

/test.php?x=10;y=20

Se arg_separator.input accetta solo &, il primo URL sarà interpretato correttamente, mentre il secondo potrebbe non essere suddiviso come previsto. Il risultato dipende dal parsing di PHP e dal contesto, ma il sintomo tipico è che uno o più parametri non compaiono in $_GET come atteso.

Questo tipo di problema è spesso subdolo perché non genera sempre un errore esplicito. Lo script funziona “quasi sempre”, poi fallisce solo con alcuni link, referrer o integrazioni. Per questo, quando si sospetta un problema di query string, vale la pena controllare prima la direttiva, poi il codice applicativo.

Relazione con WordPress, plugin e URL SEO

In WordPress, di solito arg_separator.input non è la prima cosa da controllare. Tuttavia può entrare in gioco in integrazioni particolari: endpoint custom, plugin legacy, redirect costruiti manualmente, sistemi di tracking, API interne o URL con parametri generati da software esterno.

Dal punto di vista SEO, il tema non è l’indicizzazione diretta della direttiva, ma la coerenza degli URL. Se alcune richieste vengono interpretate male, puoi ritrovarti con pagine che rispondono in modo diverso a parametri apparentemente validi. Questo può creare problemi di canonicalizzazione, tracking, filtri prodotto, paginazione o campagne con parametri UTM.

Per questo motivo, in ottica webmaster, la direttiva va considerata una piccola ma importante parte della catena di affidabilità degli URL.

Verifica dopo la modifica

Dopo aver cambiato il valore, non fermarti al semplice riavvio del servizio. Fai almeno queste verifiche:

1. controlla il valore effettivo con phpinfo() o php -i, per confermare che la modifica sia stata caricata;
2. testa un URL con i separatori previsti e verifica il contenuto di $_GET;
3. se il sito usa PHP-FPM, svuota eventuali cache applicative o reverse proxy, per evitare falsi positivi.

Un controllo utile è creare temporaneamente una pagina di test con:

<?php var_dump($_GET);

poi richiamarla con gli URL di prova. Il risultato atteso è vedere i parametri separati come previsto dalla configurazione scelta.

Errori comuni da evitare

Il primo errore è confondere questa direttiva con la costruzione degli URL. Se vuoi cambiare il modo in cui un’applicazione genera i link, spesso devi intervenire su arg_separator.output o direttamente sul codice applicativo, non su arg_separator.input.

Il secondo errore è modificare il file sbagliato. Su macchine con più versioni di PHP, o con più handler attivi, può capitare di cambiare la configurazione della CLI mentre il sito usa PHP-FPM o un altro modulo. In quel caso la modifica sembra non funzionare, ma in realtà non è stata applicata al servizio giusto.

Il terzo errore è fare cambi multipli insieme. Se tocchi anche variables_order, request_order, rewrite del web server o logiche applicative, non saprai più quale modifica ha prodotto l’effetto osservato. Per un troubleshooting serio, una variabile alla volta.

Approccio pratico in produzione

In produzione conviene seguire una sequenza semplice:

1. verifica il sintomo, ad esempio parametri mancanti o URL legacy non letti correttamente;
2. controlla il valore attuale di arg_separator.input nel contesto del sito;
3. modifica solo se il problema è coerente con il parsing dei separatori;
4. testa con una pagina di prova e con l’URL reale che genera il problema.

Se il sito è critico, pianifica un rollback immediato: ripristino del file di configurazione salvato prima della modifica e riavvio del servizio PHP interessato. Questo è un intervento piccolo, ma in un ambiente con traffico reale anche una piccola variazione può generare effetti inattesi su script vecchi o integrazioni esterne.

Buone pratiche finali

• usa & come scelta standard, salvo esigenze di compatibilità;
• verifica sempre il valore nel SAPI corretto, non solo da CLI;
• documenta la modifica se il server è gestito da più persone;
• mantieni un backup del file prima di ogni intervento;
• testa sia i link nuovi sia quelli storici, se il sito ha lunga vita o migrazioni pregresse.

In sintesi, arg_separator.input è una direttiva semplice solo in apparenza: controlla come PHP interpreta i parametri in ingresso e può incidere su compatibilità, affidabilità degli URL e comportamento di applicazioni legacy. Usarla bene significa sapere quando non toccarla, quando limitarla allo standard e quando ampliarla solo per motivi concreti e verificati.

La regola più solida resta questa: prima osserva il problema reale, poi controlla il parsing della query string, infine cambia la configurazione solo nel punto giusto e con una verifica immediata del risultato.