2. Das Proxy-Status HTTP-Feld

Das Proxy-Status HTTP-Antwortfeld ermöglicht es einem Vermittler, zusätzliche Informationen über seine Behandlung einer Antwort und der zugehörigen Anfrage zu übermitteln.

Sein Wert ist eine Liste (siehe Abschnitt 3.1 von [STRUCTURED-FIELDS]). Jedes Mitglied der Liste repräsentiert einen Vermittler, der die Antwort behandelt hat. Das erste Mitglied repräsentiert den Vermittler, der dem Ursprungsserver am nächsten ist, und das letzte Mitglied repräsentiert den Vermittler, der dem Benutzeragenten am nächsten ist.

Zum Beispiel:

Proxy-Status: revproxy1.example.net, ExampleCDN

zeigt an, dass diese Antwort zuerst von revproxy1.example.net (einem Reverse-Proxy neben dem Ursprungsserver) und dann von ExampleCDN behandelt wurde.

Vermittler bestimmen, wann es angemessen ist, das Proxy-Status-Feld zu einer Antwort hinzuzufügen. Einige entscheiden sich möglicherweise, es an alle Antworten anzuhängen, während andere dies nur tun, wenn sie speziell dafür konfiguriert sind oder wenn die Anfrage ein Header-Feld enthält, das einen Debug-Modus aktiviert.

Jedes Mitglied der Liste identifiziert den Vermittler, der den Wert eingefügt hat, und MUSS vom Typ String (Zeichenkette) oder Token sein. Abhängig vom Deployment kann dies ein Servicename sein (aber kein Software- oder Hardwareproduktname; z.B. ist "ExampleCDN" angemessen, aber "ExampleProxy" nicht, weil es das Deployment nicht identifiziert), ein Hostname ("proxy-3.example.com"), eine IP-Adresse oder eine generierte Zeichenkette.

Parameter jedes Mitglieds (gemäß Abschnitt 3.1.2 von [STRUCTURED-FIELDS]) übermitteln zusätzliche Informationen über die Behandlung der Antwort und der zugehörigen Anfrage durch diesen Vermittler; siehe Abschnitt 2.1. Obwohl alle diese Parameter OPTIONAL sind, werden Vermittler ermutigt, so viele Informationen wie möglich bereitzustellen (siehe jedoch Abschnitt 4 für Sicherheitsüberlegungen diesbezüglich).

Beim Hinzufügen eines Werts zum Proxy-Status-Feld SOLLTEN Vermittler die vorhandenen Mitglieder des Felds beibehalten, um das Debugging der gesamten Kette von Vermittlern zu ermöglichen, die die Anfrage behandeln, es sei denn, sie sind explizit so konfiguriert, dass sie sie entfernen (z.B. um zu verhindern, dass interne Netzwerkdetails durchsickern; siehe Abschnitt 4).

Ursprungsserver DÜRFEN das Proxy-Status-Feld NICHT generieren.

Proxy-Status KANN als HTTP-Trailer-Feld gesendet werden. Wenn beispielsweise ein Vermittler eine Antwort streamt und die eingehende Verbindung plötzlich beendet wird, kann Proxy-Status nur an den Trailer-Abschnitt der ausgehenden Nachricht angehängt werden, da der Header-Abschnitt bereits gesendet wurde. Da es jedoch möglicherweise auf dem Weg zum Benutzeragenten stillschweigend verworfen wird (wie es bei allen Trailer-Feldern der Fall ist; siehe Abschnitt 6.5 von [HTTP]), SOLLTE Proxy-Status NICHT als Trailer-Feld gesendet werden, es sei denn, es ist nicht möglich, es im Header-Abschnitt zu senden.

Um Empfängern zu ermöglichen, die relative Reihenfolge von Proxy-Status-Mitgliedern zu rekonstruieren, die in Trailer-Feldern übermittelt werden, mit denen, die in Header-Feldern übermittelt werden, DARF ein Vermittler Proxy-Status NICHT als Trailer-Feld senden, es sei denn, er hat auch ein Proxy-Status-Header-Feld mit demselben Mitglied (obwohl möglicherweise mit unterschiedlichen Parametern) in dieser Nachricht generiert.

Zum Beispiel würde ein Proxy, der als 'ThisProxy' identifiziert wird und eine Antwort mit einem Header-Feld empfängt:

Proxy-Status: SomeOtherProxy

seinen eigenen Eintrag zum Header-Feld hinzufügen:

Proxy-Status: SomeOtherProxy, ThisProxy

wodurch es ihm ermöglicht wird, ein Trailer-Feld anzuhängen:

Proxy-Status: ThisProxy; error=read_timeout

was es dadurch einem nachgelagerten Empfänger ermöglichen würde, zu verstehen, dass die Verarbeitung durch 'SomeOtherProxy' vor 'ThisProxy' erfolgte.

Ein Client KANN den Wert des Proxy-Status-Trailer-Felds in den Header-Abschnitt für Debugging- oder andere Zwecke (z.B. um den Zugriff zu erleichtern) befördern.

2.1. Proxy-Status-Parameter

Jedes Mitglied der Proxy-Status-Liste kann Parameter haben, die die Behandlung der Antwort durch den Proxy beschreiben. Dieser Abschnitt beschreibt diese Parameter im Detail.

2.1.1. error

Der Parameter "error" hat einen Wert vom Typ Token, der ein Proxy Error Type (Proxy-Fehlertyp) ist (Abschnitt 2.3); seine Anwesenheit zeigt an, dass der Vermittler auf ein Problem gestoßen ist, als er eine Antwort für die Anfrage erhalten wollte.

2.1.2. next-hop

Der Parameter "next-hop" hat einen Wert vom Typ String oder Byte Sequence (Bytesequenz); seine Anwesenheit zeigt den nächsten Hop an, den der Vermittler zum Weiterleiten der Anfrage verwendet hat. Dies kann eine IP-Adresse und Portnummer, ein Hostname oder eine andere Form von Bezeichner sein.

2.1.3. next-protocol

Der Parameter "next-protocol" hat einen Wert vom Typ Token oder Byte Sequence; seine Anwesenheit zeigt den ALPN-Protokollbezeichner [RFC7301] an, den der Vermittler zum Verbinden mit dem nächsten Hop verwendet hat.

2.1.4. received-status

Der Parameter "received-status" hat einen Wert vom Typ Integer (Ganzzahl); seine Anwesenheit zeigt den HTTP-Statuscode an, den der Vermittler vom Next-Hop-Server erhalten hat. Der Wert des Parameters MUSS im Bereich 100-999 einschließlich liegen.

Dieser Parameter ist nur anwendbar, wenn der error-Parameter nicht vorhanden ist. Er ist für die Verwendung gedacht, wenn der Vermittler seine eigene Antwort basierend auf der vom nächsten Hop erhaltenen Antwort generiert, aber keinen Fehler generiert.

2.1.5. details

Der Parameter "details" hat einen Wert vom Typ String; seine Anwesenheit ermöglicht es dem Proxy, zusätzliche Informationen zu übermitteln, die spezifisch für diese Antwort sind und keinen besser geeigneten Parameter haben. Dies kann implementierungsspezifische oder deployment-spezifische Informationen umfassen.

2.2. Definition neuer Proxy-Status-Parameter

Neue Proxy-Status-Parameter können durch Registrierung im Register "HTTP Proxy-Status Parameters" definiert werden.

Registrierungsanträge werden gemäß [RFC8126], Abschnitt 4.5, durch Expert Review geprüft und genehmigt. Ein Spezifikationsdokument wird geschätzt, ist aber nicht erforderlich.

Der/die Experte(n) sollte(n) bei der Bewertung von Anfragen folgende Faktoren berücksichtigen:

Community-Feedback
Ob der Wert ausreichend gut definiert ist
Generische Parameter werden gegenüber herstellerspezifischen, anwendungsspezifischen oder deployment-spezifischen Werten bevorzugt. Wenn in der Community kein generischer Wert vereinbart werden kann, sollte der Name des Parameters entsprechend spezifisch sein (z.B. mit einem Präfix, das den Hersteller, die Anwendung oder das Deployment identifiziert).
Ob der Name des Parameters mit anderen Proxy-Status-Parametern, neuen oder bestehenden Fehlertypen in Konflikt steht oder Verwirrung stiftet oder das Potenzial hat, dies in Zukunft zu tun.

Registrierungsanträge sollten die folgende Vorlage verwenden:

Name: [ein Name für den Proxy-Status-Parameter, der vom Typ Token ist]

Beschreibung: [eine Beschreibung der Semantik des Parameters]

Referenz: [zu einer Spezifikation, die diesen Parameter definiert; optional]

Hinweise: [optional]

Siehe das Register unter https://www.iana.org/assignments/http-proxy-status für Details darüber, wohin Registrierungsanträge gesendet werden sollen.