Zusammenfassung

  • HTTP/2 erlaubte, eine dauerhafte, multiplexierte Verbindung für Anfragen mit unterschiedlichen URI-Authorities wiederzuverwenden, wenn Namensauflösung und Zertifikat dies stützten. Diese Belege machten den Versuch vernünftig; sie beschrieben nicht jede interne Dienstauswahl, die der SNI-Wert des ersten Handshakes ausgelöst hatte.
  • 421 Misdirected Request weist die Zuordnung einer Origin zu einer Verbindung zurück. Der Status behauptet weder einen Umzug des URI noch eine fehlerhafte Anfrage oder ein notwendiges TLS-Versagen. Der Client darf denselben Vorgang über eine andere Verbindung wiederholen, auch bei einer nicht idempotenten Methode; ein gewöhnlicher Proxy darf 421 nicht erzeugen.
  • RFC 8336 ergänzte den HTTP/2-ORIGIN-Frame, um die Origin Set einer Verbindung vorab mitzuteilen und nach 421 beim unterstützenden Client zu korrigieren. HTTP/3 behielt den Status über QUIC bei. Das dauerhafte Problem liegt damit in der Autoritätsgrenze gemeinsam genutzter Verbindungen, nicht in TCP.

Das Zertifikat kannte beide Namen

Ein Client hat bereits eine verschlüsselte Verbindung zur ersten Website. Eine zweite Website löst auf dieselbe Adresse auf, und ihr Name ist ebenfalls durch das Zertifikat des Gegenübers gedeckt. Eine neue Verbindung würde Verhandlung, Transportzustand und Zeit kosten. Die bestehende ist authentisiert und kann in HTTP/2 mehrere unabhängige Streams gleichzeitig tragen.

Aus Sicht des Clients spricht viel für Wiederverwendung. Doch die sichtbare Identität des Endpunkts ist nicht identisch mit seinem inneren Dienstplan. Beim Aufbau kann der SNI-Wert einen Mandanten, einen TLS-Terminator, eine Portregel oder einen Backend-Pool ausgewählt haben. Ein Zertifikat kann zwei Namen korrekt beglaubigen, während der für den ersten Namen gewählte interne Weg nur dessen Dienst erreicht.

Die zweite Origin kann über eine neue Verbindung mit ihrem eigenen SNI vollkommen funktionieren. Auch die erste Verbindung kann für die erste Origin gültig bleiben. Gescheitert ist die Annahme, die zweite Origin gehöre in den Kontext der ersten Verbindung.

Der Client hatte Belege für seinen Versuch. Der Server hatte die lokal bessere Kenntnis für die Ablehnung. HTTP 421 gab dieser Differenz eine präzise Form.

Host benannte das Ziel, nicht den Antwortberechtigten

HTTP hatte schon zuvor gelernt, Transportadresse und benannten Ressourcenraum zu trennen. Als viele Websites dieselbe IP-Adresse nutzten, konnte das TCP-Ziel allein nicht mehr zeigen, welche Website gemeint war. HTTP/1.1 verlangte Host; HTTP/2 und HTTP/3 verwenden dafür gewöhnlich :authority.

Damit beantwortet der Client: Welche Origin will ich ansprechen? Offen bleibt die Frage des Empfängers: Ist diese Origin in diesem Dienst und in diesem Verbindungskontext eingerichtet?

Die heutige HTTP-Semantik in RFC 9110 behält beide Schritte. Host und Port des Ziel-URI grenzen den Namensraum von anderen ab, die ein Server verwalten kann. Nachdem er das Ziel erkannt hat, entscheidet der Server weiterhin, ob er selbst verarbeitet, weiterleitet, umleitet, ablehnt oder die Verbindung beendet, und prüft Anforderungen von Schema und Kontext.

Host erklärt die Absicht der Anfrage. Es ernennt nicht jeden hinter dem Socket erreichbaren Prozess zum Vertreter des genannten Namens.

HTTP/2 machte die Schlussfolgerung wirtschaftlich attraktiv

Die ursprüngliche HTTP/2-Spezifikation RFC 7540 erschien im Mai 2015. Dauerhafte Verbindungen und Multiplexing erhöhten den Wert einer bereits geöffneten Verbindung. Sie durfte Anfragen mit verschiedenen URI-Authority-Komponenten tragen, solange der Origin-Server als autoritativ erschien.

Bei TCP ohne TLS hing das unter anderem davon ab, dass der neue Host auf dieselbe IP-Adresse auflöste. Bei HTTPS musste das vorhandene Zertifikat zusätzlich alle Prüfungen bestehen, die der Client für eine neue Verbindung zum neuen Host ausgeführt hätte. Mehrere subjectAltName-Einträge oder ein passender Wildcard-Name konnten daher mehrere Origins abdecken.

Das war kein blindes Zusammenlegen. Es war eine vorsichtige Entscheidung auf Grundlage äußerlich prüfbarer Fakten. Die interne Auswahl hinter der TLS-Grenze blieb jedoch möglicherweise unsichtbar.

RFC 7540 beschrieb einen TLS-Terminator, der anhand des SNI einen Origin-Server auswählt. Eine spätere Anfrage für einen weiteren zertifikatsgedeckten Namen kann über die vorhandene Verbindung im falschen Kontext landen, obwohl die gesamte Infrastruktur diesen Namen an anderer Stelle bedienen kann.

DNS musste nicht falsch, das Zertifikat nicht gefälscht und die HTTP-Nachricht nicht missgebildet sein. Dem Client fehlte nur die letzte Zuordnungsinformation, die der Empfänger besaß.

421 lehnte eine Kante ab

RFC 7540 führte 421 Misdirected Request ein. Die aktuelle Definition steht inzwischen in RFC 9110 und gehört damit zur allgemeinen HTTP-Semantik.

Der Server kann oder will für den Ziel-URI keine autoritative Antwort erzeugen. Das Ziel passt womöglich zu keiner dort konfigurierten Origin oder nicht zum Kontext der Verbindung, über die es eingetroffen ist.

Der Status erklärt die Origin nicht für verschwunden. Er meldet keinen Umzug und gibt keinen Ersatz-URI vor. Er sagt auch nicht, dass die Verbindung für jeden anderen Zweck unbrauchbar sei. Er weist die konkrete Beziehung „diese Origin über diese Verbindung“ zurück.

Ein Origin-Server oder ein in seinem Auftrag handelndes Gateway kann 421 senden. Ein Proxy darf den Status nach RFC 9110 nicht erzeugen. So bleibt die Aussage an die Grenze gebunden, deren Konfiguration sie beschreibt. Würde jeder Weiterleitungsknoten denselben Befund herstellen dürfen, könnte der Client eine Ablehnung der Origin nicht von einer bloßen Wegewahl des Vermittlers unterscheiden.

Auch negative Evidenz braucht nachvollziehbare Herkunft.

Erreichbarkeit, Identität und Kontextannahme

Drei Aussagen liegen nahe beieinander, sind aber nicht gleich. Die Verbindung erreicht einen Endpunkt. Der Endpunkt authentisiert sich mit einem für die Ziel-Origin akzeptierten Zertifikat. Die Bereitstellung ist bereit und fähig, auf genau dieser Verbindung für die Origin autoritativ zu antworten.

Die ersten beiden Aussagen rechtfertigen einen Wiederverwendungsversuch. Sie erzwingen die dritte nicht. Ein Zertifikat belegt die Verfügung über einen privaten Schlüssel für akzeptierte Identitäten. Es belegt nicht, dass jeder enthaltene Name auf jeder Verbindung denselben Mandanten, dieselbe Anwendung, denselben Port oder denselben Backend-Pool nutzt.

Umgekehrt macht ein 421 die ersten Belege nicht falsch. Das Zertifikat kann für die zweite Origin gültig bleiben, und die bestehende Verbindung kann weiterhin die erste bedienen.

421 hält jedes Beweismittel in seinem Zuständigkeitsbereich. Die Autorität der Verbindung wird nicht breiter als die Konfiguration, die sie tatsächlich trägt.

Der neue Versuch änderte den Kontext

Nach 421 darf der Client die Anfrage über eine andere Verbindung wiederholen, etwa über eine frische, originspezifische Verbindung oder einen geeigneten alternativen Dienst. Das gilt auch für eine nicht idempotente Methode.

Diese Erlaubnis ist keine allgemeine Freigabe, Schreibvorgänge nach beliebigen Netzfehlern zu wiederholen. 421 ist eine typisierte Ablehnung: Der Antwortende hat die autoritative Verarbeitung der Ziel-Origin in diesem Kontext verweigert. Eine neue Verbindung korrigiert die Zustellung und wiederholt nicht einfach nach einem unbekannten Anwendungsergebnis.

Dennoch bleibt es eine Option. Ein Request-Body kann nicht reproduzierbar sein, Zugangsdaten können an den Kanal gebunden sein, eine lokale Richtlinie kann Wiederholung untersagen oder eine irreversible Aktion kann Bestätigung erfordern.

Vor allem muss sich eine Bedingung ändern. Unbegrenztes erneutes Senden auf derselben abgelehnten Verbindung ist keine Wiederherstellung. Ziel-URI, Methode und Absicht bleiben gleich; die neue Verbindung kann aber den SNI der Ziel-Origin tragen und dadurch eine andere Frontend- oder Backend-Auswahl auslösen, selbst wenn Adresse und Zertifikat am Ende identisch sind.

Die Anfrage behält ihre Bedeutung und wechselt ihr Beförderungsmittel.

Kein Redirect unter anderem Namen

Eine Umleitung schlägt ein anderes Ziel vor und liefert gewöhnlich einen Location-Wert. Sie kann Host, Pfad, Autorität, Cache-Schlüssel und den Geltungsbereich von Zugangsdaten ändern. 421 nennt keinen Ersatz-URI.

Wer den Status wie einen Redirect behandelt, lässt einen internen Zuordnungsfehler die öffentliche Identität der Anfrage verändern. Zugangsdaten könnten eine andere Autorität erreichen, interne Namen könnten sichtbar werden, oder eine fehlerhafte Dienstkarte würde als legitimer Ressourcenwechsel erscheinen.

421 ist ebenso wenig 400 Bad Request, denn die Nachricht kann syntaktisch korrekt sein. Es ist nicht 403 Forbidden, weil nicht die Berechtigung des Nutzers im Mittelpunkt steht. Und es ist kein TLS-Alarm: Gerade die erfolgreiche Zertifikatsprüfung kann den Wiederverwendungsversuch ausgelöst haben.

Ein eng definierter Status verhindert, dass eine Schicht die Bedeutung der anderen übernimmt.

ORIGIN gab Wissen vor dem Fehlversuch weiter

Die reaktive Korrektur kostet Zeit: Anfrage senden, 421 empfangen, andere Verbindung auswählen. RFC 8336 definierte im März 2018 den HTTP/2-Frame ORIGIN, mit dem ein Server die für eine Verbindung nutzbaren Origins ankündigen kann.

Die Menge heißt Origin Set. Sobald sie initialisiert ist, darf ein unterstützender Client die Verbindung nicht für eine darin fehlende Origin als autoritativ ansehen. Die Einträge sind konkrete Origins; Wildcards sind nicht erlaubt. Ein weit gefasstes Wildcard-Zertifikat wird daher nicht automatisch zu einer ebenso weiten Betriebsankündigung.

ORIGIN beschreibt eine Eigenschaft einer einzelnen Verbindung und wird hopweise verarbeitet. Vermittler leiten den Frame nicht weiter, und ein Client mit konfiguriertem Proxy ignoriert ORIGIN von diesem Proxy. Spätere Frames können Origins hinzufügen, doch die Zertifikatsprüfung bleibt erforderlich. Die Liste ist ein Betriebssignal, keine neue Legitimation.

Empfängt ein unterstützender Client 421, entfernt er die betreffende Origin aus der Origin Set dieser Verbindung. Die Ablehnung wird damit zu korrigiertem Wissen für die nächste Auswahl.

Die richtige Erinnerung ist an Origin und Verbindung gebunden. Eine globale Sperre würde aus einem lokalen Befund zu viel lernen; sofortiges Vergessen würde denselben Versuch wiederholen.

Alt-Svc benannte einen Weg, nicht dessen gesamte Autorität

Alt-Svc kann einen anderen Host, Port oder ein anderes Protokoll als äquivalenten Dienst einer Origin ankündigen. Ein Client kann diesen Weg nach 421 wählen. Die Ankündigung ersetzt aber weder die Autoritätsprüfungen noch verändert sie automatisch die Origin Set.

DNS liefert Erreichbarkeitshinweise, das Zertifikat Identität, Alt-Svc eine Alternative und ORIGIN die beabsichtigte Nutzung einer Verbindung. Der Empfänger kennt schließlich den tatsächlich ausgewählten Dienstkontext. Keine dieser Aussagen beweist alle anderen.

Sonst würde sich die Signalkette selbst legitimieren. 421 lässt der empfangenden Grenze die Möglichkeit, die letzte Kombination abzulehnen, ohne jede einzelne Aussage zu verwerfen.

Gerade die Begrenzung der Signale macht ihre Zusammenarbeit belastbar.

HTTP/3 ersetzte den Transport, nicht die Grenze

Die aktuelle HTTP/2-Spezifikation RFC 9113 ersetzte RFC 7540 und behielt Wiederverwendung zwischen Origins sowie 421 bei. RFC 9114 brachte HTTP auf QUIC und bewahrte denselben Status.

Auch HTTP/3-Verbindungen sind dauerhaft und können für verschiedene URI-Authorities genutzt werden. Bevor ein Client eine vorhandene Verbindung für eine neue Origin verwendet, muss er das Zertifikat für diese Origin validieren. Ist es ungeeignet, ist Wiederverwendung verboten. Ist es geeignet, kann der Server dennoch 421 senden, wenn die konkrete HTTP/3-Verbindung die Origin nicht bedienen soll.

Diese Geschichte trennt das Prinzip vom ursprünglichen Transport. 421 entstand in HTTP/2, wanderte in die versionsunabhängige Semantik und blieb in HTTP/3. Das Problem war kein Zufall von TCP oder eines Frame-Formats.

Sobald ein effizienter Kanal plausibel mehrere Namen tragen kann, während der Empfänger zusätzlichen Dienstkontext besitzt, braucht die Autorität ein begrenztes Vetorecht.

Die abgelehnte Beziehung beobachten

Eine Gesamtzahl von 421-Antworten erklärt nichts. Zu jedem Ereignis gehören Schema, Host und Port des Ziels, Methode, HTTP-Version, Verbindungs- und Streamkennung, entfernter Endpunkt, SNI, ALPN, Zertifikatsnamen, das für die Wiederverwendung herangezogene DNS-Ergebnis, Alt-Svc-Herkunft, Origin Set, ausgewähltes Frontend und Backend, Rolle des Ausstellers sowie Kennung und Ergebnis der Folgeverbindung.

Scheitert nur die geteilte Verbindung und gelingt eine frische originspezifische, ist die Kontextauswahl die führende Erklärung. Scheitern beide, kann die Origin insgesamt fehlen. Tritt der Fehler nur in einer Region auf, sollten Zertifikate, Ankündigungen und Backends auf unterschiedliche Ausrollzeitpunkte geprüft werden.

Ein einzelner 421 kann eine gesunde Korrektur einer optimistischen Leistungsentscheidung sein. Wiederholung ohne Konvergenz ist das Warnsignal.

Gemeinsamer Transport war keine gemeinsame Herrschaft

Verbindungswiederverwendung spart Handshakes, Zustand und Latenz. 421 verlangt nicht für jeden Namen einen eigenen Kanal und erklärt nicht jede Abweichung zum Angriff. Der Status macht die Optimierung widerrufbar.

Der Client entscheidet vorläufig mit den sichtbaren Belegen. Die empfangende Bereitstellung entscheidet mit SNI, Mandant, Port und Backend, ob sie für die Origin antworten kann. Bei Widerspruch bleiben URI und Operation erhalten, während der Kontext gewechselt wird.

Ohne dieses begrenzte Nein könnte die erste Verbindung faktische Gewalt über jeden Namen eines gemeinsamen Zertifikats gewinnen. Aus einer Transportersparnis würde eine Zentralisierung der Dienstentscheidung.

Das aktuelle IANA-Verzeichnis der HTTP-Statuscodes führt 421 als Misdirected Request und verweist auf RFC 9110. Die Registrierung fixiert einen interoperablen Namen und Bezug; sie belegt weder Nutzungshäufigkeit noch ein einheitliches Wiederholungsverhalten oder die korrekte Konfiguration einer konkreten Bereitstellung.

Die Verbindung war gültig. Die zweite Origin war ebenfalls real. Nicht vorhanden war nur das Mandat der ersten Verbindung, die zweite zu vertreten. 421 machte genau diese Abwesenheit sichtbar.