Zusammenfassung

  • Der HTTP/1.1-Status 305 Use Proxy von 1997 forderte den Empfänger auf, seine Anfrage über den in Location genannten Proxy zu wiederholen.
  • Die Ausgabe von 1999 begrenzte die Anweisung auf eine Anfrage und Antworten des Ursprungsservers. 2014 wurde sie wegen Sicherheitsbedenken bei einer Proxy-Konfiguration innerhalb des HTTP-Austauschs verworfen.

Sie fragen im Laden nach einem Buch. Der Laden gibt Ihnen die Adresse eines Vermittlers und möchte, dass Sie die Frage zuerst dort noch einmal stellen. Das Buch ist weiterhin im Laden. Geändert wird der Weg Ihrer Anfrage. HTTP hatte dafür den Statuscode 305 Use Proxy: Eine Antwort sollte den Client zu einem Proxy schicken, der fortan zwischen ihm und dem Ziel stand.

RFC 2068 vom Januar 1997 legte die Idee knapp fest. Die gewünschte Ressource sollte über den Proxy aus dem Feld Location erreicht werden; der Empfänger sollte die Anfrage auf diesem Weg wiederholen. Derselbe RFC beschrieb einen Proxy als weiterleitenden Agenten, der Anfragen annimmt und beim Weiterreichen gegebenenfalls umformt. Der zusätzliche Schalter auf dem Weg war eine reale Maschine mit Zugriff auf den Verkehr.

In der Familie der Weiterleitungen wirkte 305 vertraut, betraf aber eine andere Entscheidung. Ein 301 gibt eine neue URI der Ressource an. Bei 305 blieb die Ressource am Ort, während der Server eine Zwischenstation auswählte. Der Client verfügt gewöhnlich über eigene Proxy-Einstellungen und Vertrauensgrenzen. Wie lange durfte die Antwort seine Route beeinflussen? Und wer durfte diese Antwort überhaupt erzeugen?

RFC 2616 vom Juni 1999 beantwortete beides mit Beschränkungen. 305 galt nur für diese eine Anfrage; ausschließlich der Ursprungsserver durfte es senden. Eine Anmerkung hält fest, dass RFC 2068 beide Grenzen offengelassen hatte und ihre Missachtung erhebliche Sicherheitsfolgen hatte. Die erste Grenze verhinderte die dauerhafte Neufassung der Proxy-Einstellung durch eine einzelne Antwort. Die zweite nahm Vermittlern die Möglichkeit, in fremdem Namen weitere Vermittler einzusetzen.

Die Grundidee blieb dennoch bestehen: Ausgerechnet die laufende HTTP-Unterhaltung sollte die Proxy-Wahl für ihre Fortsetzung liefern. RFC 7231 von 2014 erklärte 305 für veraltet. Die Änderungsübersicht nennt den Grund ausdrücklich: Sicherheitsbedenken bei einer Proxy-Konfiguration im selben Protokollkanal. Die heikle Entscheidung lag in der Antwort selbst: Sie wollte den Proxy bestimmen, der die nächste Anfrage des Clients entgegennahm.

RFC 9110 von 2022 führt die Nummer weiterhin in der Tabelle und kennzeichnet sie als veraltet. Das ist ein nützliches Relikt für Leser alter HTTP-Aufzeichnungen. Der Wegweiser bleibt im Archiv erkennbar, während seine Anweisung ihre heutige Gültigkeit verloren hat.

Ein Proxy empfängt die Anfrage, bevor sie die eigentliche Adresse erreicht. Wer ihn auswählt, bestimmt damit einen Teil des Transaktionswegs. 305 überließ diese Entscheidung einer Serverantwort; 1999 bekam sie Zäune, 2014 wurde das Tor geschlossen. An einer kleinen Statuszahl wurde sichtbar, dass die Straße zum Ziel selbst eine Vertrauensfrage ist.