2. Il campo HTTP Proxy-Status

Il campo di risposta HTTP Proxy-Status consente a un intermediario di trasmettere informazioni aggiuntive sulla sua gestione di una risposta e della richiesta associata.

Il suo valore è una List (lista) (vedere sezione 3.1 di [STRUCTURED-FIELDS]). Ogni membro della lista rappresenta un intermediario che ha gestito la risposta. Il primo membro rappresenta l'intermediario più vicino al server di origine, e l'ultimo membro rappresenta l'intermediario più vicino all'agente utente.

Ad esempio:

Proxy-Status: revproxy1.example.net, ExampleCDN

indica che questa risposta è stata gestita prima da revproxy1.example.net (un proxy inverso adiacente al server di origine) e poi da ExampleCDN.

Gli intermediari determinano quando è appropriato aggiungere il campo Proxy-Status a una risposta. Alcuni potrebbero decidere di aggiungerlo a tutte le risposte, mentre altri potrebbero farlo solo quando specificamente configurati o quando la richiesta contiene un campo di intestazione che attiva una modalità di debug.

Ogni membro della lista identifica l'intermediario che ha inserito il valore e DEVE avere un tipo String (stringa) o Token. A seconda del deployment, questo potrebbe essere un nome di servizio (ma non un nome di prodotto software o hardware; ad esempio, "ExampleCDN" è appropriato, ma "ExampleProxy" non lo è perché non identifica il deployment), un hostname ("proxy-3.example.com"), un indirizzo IP o una stringa generata.

I parametri di ciascun membro (secondo la sezione 3.1.2 di [STRUCTURED-FIELDS]) trasmettono informazioni aggiuntive sulla gestione da parte di quell'intermediario della risposta e della richiesta associata; vedere sezione 2.1. Sebbene tutti questi parametri siano OPZIONALI, gli intermediari sono incoraggiati a fornire quante più informazioni possibili (ma vedere sezione 4 per le considerazioni sulla sicurezza nel farlo).

Quando si aggiunge un valore al campo Proxy-Status, gli intermediari DOVREBBERO preservare i membri esistenti del campo per consentire il debug dell'intera catena di intermediari che gestiscono la richiesta, a meno che non siano esplicitamente configurati per rimuoverli (ad esempio, per impedire la fuga di dettagli della rete interna; vedere sezione 4).

I server di origine NON DEVONO generare il campo Proxy-Status.

Proxy-Status PUÒ essere inviato come campo di trailer HTTP. Ad esempio, se un intermediario sta inviando in streaming una risposta e la connessione in entrata termina improvvisamente, Proxy-Status può essere aggiunto solo alla sezione di trailer del messaggio in uscita poiché la sezione di intestazione è già stata inviata. Tuttavia, poiché potrebbe essere silenziosamente scartato lungo il percorso verso l'agente utente (come nel caso di tutti i campi di trailer; vedere sezione 6.5 di [HTTP]), Proxy-Status NON DOVREBBE essere inviato come campo di trailer a meno che non sia possibile inviarlo nella sezione di intestazione.

Per consentire ai destinatari di ricostruire l'ordine relativo dei membri Proxy-Status trasmessi nei campi di trailer con quelli trasmessi nei campi di intestazione, un intermediario NON DEVE inviare Proxy-Status come campo di trailer a meno che non abbia anche generato un campo di intestazione Proxy-Status con lo stesso membro (sebbene potenzialmente con parametri diversi) in quel messaggio.

Ad esempio, un proxy identificato come 'ThisProxy' che riceve una risposta con un campo di intestazione:

Proxy-Status: SomeOtherProxy

aggiungerebbe la propria voce al campo di intestazione:

Proxy-Status: SomeOtherProxy, ThisProxy

consentendogli così di aggiungere un campo di trailer:

Proxy-Status: ThisProxy; error=read_timeout

il che consentirebbe quindi a un destinatario a valle di capire che l'elaborazione da parte di 'SomeOtherProxy' è avvenuta prima di 'ThisProxy'.

Un client PUÒ promuovere il valore del campo di trailer Proxy-Status nella sezione di intestazione per scopi di debug o altri (ad esempio, per renderlo più facile da accedere).

2.1. Parametri Proxy-Status

Ogni membro della lista Proxy-Status può avere parametri che descrivono la gestione della risposta da parte del proxy. Questa sezione descrive in dettaglio tali parametri.

2.1.1. error

Il parametro "error" ha un valore di tipo Token che è un Proxy Error Type (tipo di errore proxy) (sezione 2.3); la sua presenza indica che l'intermediario ha riscontrato un problema nell'ottenere una risposta per la richiesta.

2.1.2. next-hop

Il parametro "next-hop" ha un valore di tipo String o Byte Sequence (sequenza di byte); la sua presenza indica il prossimo hop che l'intermediario ha utilizzato per inoltrare la richiesta. Questo potrebbe essere un indirizzo IP e un numero di porta, un hostname o qualche altra forma di identificatore.

2.1.3. next-protocol

Il parametro "next-protocol" ha un valore di tipo Token o Byte Sequence; la sua presenza indica l'identificatore di protocollo ALPN [RFC7301] utilizzato dall'intermediario per connettersi al prossimo hop.

2.1.4. received-status

Il parametro "received-status" ha un valore di tipo Integer (intero); la sua presenza indica il codice di stato HTTP ricevuto dall'intermediario dal server del prossimo hop. Il valore del parametro DEVE essere nell'intervallo 100-999 incluso.

Questo parametro è applicabile solo quando il parametro error non è presente. È destinato ad essere utilizzato quando l'intermediario genera la propria risposta basata sulla risposta ricevuta dal prossimo hop, ma non genera un errore.

2.1.5. details

Il parametro "details" ha un valore di tipo String; la sua presenza consente al proxy di trasmettere informazioni aggiuntive specifiche per questa risposta e che non hanno un parametro più adatto. Questo potrebbe includere informazioni specifiche dell'implementazione o del deployment.

2.2. Definizione di nuovi parametri Proxy-Status

Nuovi parametri Proxy-Status possono essere definiti registrandoli nel registro "HTTP Proxy-Status Parameters".

Le richieste di registrazione sono esaminate e approvate tramite Expert Review, secondo [RFC8126], sezione 4.5. Un documento di specifica è apprezzato ma non richiesto.

L'esperto o gli esperti dovrebbero considerare i seguenti fattori durante la valutazione delle richieste:

Feedback della comunità
Se il valore è sufficientemente ben definito
I parametri generici sono preferiti rispetto ai valori specifici del fornitore, specifici dell'applicazione o specifici del deployment. Se un valore generico non può essere concordato nella comunità, il nome del parametro dovrebbe essere corrispondentemente specifico (ad esempio, con un prefisso che identifica il fornitore, l'applicazione o il deployment).
Se il nome del parametro è in conflitto o causa confusione con altri parametri Proxy-Status, tipi di errore nuovi o esistenti, o ha il potenziale per farlo in futuro.

Le richieste di registrazione dovrebbero utilizzare il seguente modello:

Nome: [un nome per il parametro Proxy-Status che è di tipo Token]

Descrizione: [una descrizione della semantica del parametro]

Riferimento: [a una specifica che definisce questo parametro; opzionale]

Note: [opzionale]

Vedere il registro all'indirizzo https://www.iana.org/assignments/http-proxy-status per i dettagli su dove inviare le richieste di registrazione.