Come un proxy di inoltro gestisce un’intestazione API personalizzata

Un’API può portare la propria versione in un campo di richiesta personalizzato come API-Version. Un normale proxy di inoltro non dovrebbe scartare quel campo solo perché il nome non gli è familiare. HTTP impone di inoltrare i campi non riconosciuti, salvo che si applichi un’eccezione definita o una politica configurata.

Il campo Connection è una di tali eccezioni. Confronta queste richieste illustrative:

API-Version: 2026-10
Connection: keep-alive

Qui il campo dell’API non è stato designato come locale a questa connessione. Nell’esempio seguente il mittente ne cambia esplicitamente la portata:

API-Version: 2026-10
Connection: API-Version

Un proxy di inoltro rimuove i campi nominati da Connection prima dell’inoltro e rimuove o sostituisce le istruzioni stesse specifiche della connessione. Un’intestazione applicativa destinata all’origine non dovrebbe quindi comparire in quell’elenco di token.

Individua il punto in cui il campo cambia

Confronta la richiesta costruita dal client, i campi ricevuti e inoltrati dal proxy e ciò che ha ricevuto l’origine. Un client può omettere un’intestazione prima che il proxy la veda; un filtro configurato può rimuoverla deliberatamente; un server può rifiutare una richiesta per aver superato un limite di intestazioni.

Non dedurre una rimozione silenziosa soltanto da una soglia di dimensione delle intestazioni segnalata in una distribuzione vecchia. Limiti e comportamento di rifiuto appartengono ai componenti e alla configurazione reali. Conserva la risposta HTTP e i registri pertinenti insieme all’osservazione.

Per HTTPS da estremo a estremo dentro un tunnel CONNECT ordinario, il proxy non può leggere né rimuovere selettivamente il campo API interno. L’ispezione delle intestazioni spetta allora agli estremi TLS o a un intermediario di ispezione esplicitamente fidato.