Streamable HTTP, drei Epochen und der aktuelle Wire-Vertrag

Der Remote-HTTP-Transport von MCP hat in etwa zwei Jahren drei verschiedene Wire-Protokoll-Generationen durchlaufen. Der HTTP+SSE-Transport vom 05.11.2024 nutzte zwei Endpunkte und einen langlebigen Stream; er ist seit dem 26.03.2025 veraltet und kann in Zukunft entfernt werden. Streamable HTTP löste ihn am 26.03.2025 mit einem einzigen Endpunkt ab – doch diese erste Form enthielt noch protokollseitige Sitzungen, einen eigenständigen GET-Stream, vom Server initiierte Anfragen über SSE sowie wiederaufnehmbare Streams. Die Überarbeitung vom 28.07.2026 hat diese Mechanismen entfernt. Was bleibt, ist ungewöhnlich sauber: Jede JSON-RPC-Nachricht des Clients wird als eigener POST gesendet, Antwortanfragen sind entweder ein einzelnes JSON-Objekt oder ein auf diese Anfrage begrenzter SSE-Stream, und ausgewählte Anfragemetadaten werden in Header gespiegelt, sodass Vermittler den Datenverkehr routen und prüfen können, ohne den Body parsen zu müssen. Diese letzte Designentscheidung ist es wert, genauer betrachtet zu werden.

Ein Load Balancer routet basierend auf einem Header, während der Server den Body ausführt, und beide stimmen nicht überein. Das ist in dieser Spezifikation kein hypothetisches Szenario – es ist der explizite Grund für die Existenz einer ganzen Validierungsregel. Der Transport vom 28.07.2026 berücksichtigt ausdrücklich Vermittler zwischen Client und Server, und ein Großteil des neuen Header-Vertrags ergibt erst dann Sinn, wenn man ihn unter diesem Aspekt betrachtet.

1. Drei Ären

05.11.2024 – HTTP+SSE. Zwei Endpunkte. Der Client sendete einen GET-Request, der einen SSE-Stream öffnete, dessen erstes Ereignis ein endpoint -Ereignis war, das dem Client mitteilte, wohin er POSTen sollte. Alles, was vom Server initiiert wurde, kam über den langlebigen Stream an. Seit dem 26.03.2025 gemäß der Feature-Lifecycle-Richtlinie veraltet; neuen Implementierungen wird davon abgeraten, diesen zu verwenden.

26.03.2025 bis 25.11.2025 – Streamable HTTP, erste Form. Ein einzelner MCP-Endpunkt, was eine bedeutende Vereinfachung darstellte. Doch vier Mechanismen hielten ihn zustandsbehaftet: Server konnten über einen Mcp-Session-Id -Header eine Sitzung zuweisen, die mit einem HTTP DELETE beendet wurde; Clients konnten mit GET einen eigenständigen SSE-Stream öffnen, um vom Server initiierte Nachrichten zu empfangen; Server konnten JSON-RPC- requests über SSE-Streams senden; und Streams waren über Last-Event-IDwiederaufnehmbar.

28.07.2026 – die aktuelle Form. Keiner dieser vier Mechanismen ist geblieben. Die Revisionshinweise listen die Entfernungen klar auf: Der GET-Stream-Endpunkt und die protokollseitigen Sitzungen sind weg, und die folgenden Abschnitte ergänzen, dass Streams nicht wiederaufnehmbar sind und Server keine unabhängigen Anfragen über einen Stream senden dürfen.

Ein Server, der nur die aktuelle Revision implementiert, verarbeitet älteren Datenverkehr mit dem festgelegten Verhalten: GET oder DELETE an den MCP-Endpunkt ergibt 405 Method Not Allowed; ein Mcp-Session-Id Header wird ignoriert und es wird keine Sitzungskennung erstellt oder zurückgegeben; ein Last-Event-ID Header wird ignoriert.

2. Das Wire-Protokoll

Der Server stellt einen einzigen HTTP-Endpunktpfad bereit – den MCP-Endpunkt –, der POST unterstützt. Die Sicherheitsgrundlage des Transports ist vor jeder Wire-Optimierung entscheidend: Server müssen den Origin Header bei eingehenden Verbindungen validieren und bei einem vorhandenen, aber ungültigen Ursprung den Status 403 zurückgeben; lokal ausgeführte Server sollten an localhost statt an alle Schnittstellen gebunden sein; zudem sollten Server Verbindungen authentifizieren. Diese Anforderungen dienen dazu, das Risiko von DNS-Rebinding und unbefugtem Zugriff zu verringern.

Senden. Jede JSON-RPC-Nachricht vom Client erfolgt als eigener POST. Der Client muss einen Accept Header einfügen, der sowohl application/json als auch text/event-streamauflistet, und der Body muss eine einzelne JSON-RPC-Anfrage oder -Benachrichtigung enthalten. Clients dürfen keine JSON-RPC-Antworten senden. Ein Detail ist für Implementierer wichtig: Obwohl der Transport das Verhalten eines Benachrichtigungs-POSTs definiert, legt das Kernprotokoll vom 28.07.2026 keine Client-zu-Server-Benachrichtigungen über Streamable HTTP fest und definiert keine Metadaten-Header-Anforderungen für Benachrichtigungs-POSTs.

Benachrichtigungen. Akzeptiert der Server eine, sendet er 202 Accepted ohne Body zurück; andernfalls einen HTTP-Fehlerstatus, optional mit einer JSON-RPC-Fehlerantwort ohne id.

Anfragen. Der Server sendet entweder Content-Type: application/json mit einem einzelnen JSON-Objekt oder Content-Type: text/event-stream mit einem SSE-Stream, der auf diese Anfrage begrenzt ist. Der Client muss beides unterstützen – der Server wählt dies pro Anfrage, sodass ein Client, der nur eine Methode beherrscht, unvorhersehbar ausfallen wird.

Was über einen Antwort-Stream übertragen wird. Der Server kann Benachrichtigungen zur ursprünglichen Anfrage – Fortschritts- und Protokollmeldungen – vor der endgültigen Antwort senden; die endgültige Antwort sollte den Stream beenden. Der Server darf keine unabhängigen JSON-RPC-Anfragen darüber senden. Dies ist der explizite Bruch mit früheren Revisionen.

Abbruch. Das Schließen des SSE-Antwort-Streams muss vom Server als Abbruch der Anfrage behandelt werden. Da jede Anfrage einen eigenen Stream hat, ist die Trennung eindeutig. Die Abbruchbenachrichtigung des Kernprotokolls wird nur bei stdio verwendet; bei diesem Transport gibt es keine Abbruchnachricht und es wird auch keine erwartet.

3. Was aus serverinitiierten Aufgaben wurde

Zwei Dinge erforderten zuvor einen Kanal vom Server zum Client; sie wurden nun in verschiedene Mechanismen aufgeteilt.

Den Client um etwas bitten – Sampling, Elicitation, Roots – ist nun als Eingabeanfrage unter dem Muster für Multi-Round-Trip-Anfragen in die Ergebnisse eingebettet. Der Server sendet ein InputRequiredResult überträgt inputRequests; der Client sammelt die Anfragen und wiederholt den ursprünglichen Aufruf mit den passenden inputResponses. Es handelt sich um einen zweiten POST-Request, nicht um einen Push.

Langlebige Änderungsbenachrichtigungen – wie Änderungen an der Tool-Liste oder Ressourcen-Updates – werden durch das Senden eines subscriptions/listen -Requests abgerufen, dessen Antwort selbst ein SSE-Stream ist. Dieser bleibt geöffnet und liefert nur die Benachrichtigungstypen, für die sich der Client entschieden hat. Anforderungsbezogene Benachrichtigungen wie Fortschrittsanzeigen erscheinen dort nicht; sie fließen ausschließlich über den Stream der jeweiligen Anfrage, zu der sie gehören.

Diese Trennung ist sauberer, als sie klingt. Der standardisierte langlebige Benachrichtigungsstream existiert, weil der Client ihn angefordert hat, und sein Inhalt wird durch das Abonnement des Clients gefiltert. Aufgaben mit mehreren Roundtrips können auf der MCP-Transportebene zustandslos bleiben, da der Server den benötigten Kontext in requestState kodieren kann und der Client diesen opaken Wert bei einem erneuten Versuch zurückgibt.

4. Zwei Details, die hinter einem Proxy Probleme bereiten

Die Spezifikation enthält zwei operative Hinweise, die existieren, weil SSE und Reverse-Proxys ein schwieriges Verhältnis zueinander haben.

Pufferung. Beim Initiieren eines SSE-Streams sollten Server X-Accel-Buffering: noeinfügen. Dies weist Reverse-Proxys wie nginx an, die Antwortpufferung zu deaktivieren. Ohne diese Anweisung kann ein Proxy Nachrichten sammeln, bevor er sie weiterleitet – was zu Latenzzeiten führt und den Zweck des Streamings zunichtemacht. Wenn gestreamte Fortschrittsaktualisierungen gebündelt am Ende eintreffen, ist die Antwortpufferung eines der ersten Zwischenverhalten, das überprüft werden sollte.

Keep-alives. Bei langlebigen Streams, insbesondere der subscriptions/listen Antwort, sollten Server regelmäßig eine SSE-Kommentarzeile ausgeben – eine Zeile, die mit einem Doppelpunkt beginnt –, um die Verbindung aufrechtzuerhalten. So wird verhindert, dass Zwischenstationen oder Timeouts bei Inaktivität eine ruhige Verbindung schließen. Gemäß der SSE-Spezifikation enthalten Kommentare keine Ereignisdaten, und Clients müssen solche Zeilen ignorieren, anstatt sie als fehlerhaft zu behandeln.

5. Der Header-Vertrag

Dies ist der Teil, der den Transport grundlegend von einer JSON-RPC-über-HTTP-Konvention unterscheidet. Die Spezifikation beschreibt den Zweck direkt: Der Transport spiegelt ausgewählte JSON-RPC-Body-Felder in HTTP-Header wider, damit Zwischenstationen – Load Balancer, Gateways, Observability-Tools – Anfragen weiterleiten und prüfen können, ohne den Body parsen zu müssen.

MCP-Protocol-Version – erforderlich bei jedem POST; der Wert muss mit der Protokollversion im _meta-Feld des Bodys übereinstimmen. Eine Abweichung wird mit 400 Bad Request und einem HeaderMismatch -Fehler abgelehnt. Eine Version, die der Server nicht implementiert, führt zu 400 mit einem Fehler, der die unterstützten Versionen auflistet. Eine nicht implementierte Methode führt zu 404 mit dem JSON-RPC-Fehler -32601, was sie von der eines Legacy-Servers unterscheidet. 404.

Mcp-Method – spiegelt method. Erforderlich für alle JSON-RPC-Anfragen.

Mcp-Name – spiegelt params.name oder params.uri. Erforderlich für tools/call, resources/readsowie prompts/get.

Für JSON-RPC-Anfragen sind diese Standard-Request-Header zur Einhaltung der oben genannten Scopes erforderlich. Benachrichtigungs-POSTs stellen einen separaten Sonderfall dar: Diese Revision definiert zwar deren Transportmechanik, jedoch nicht deren Anforderungen an Metadaten-Header. Ein minimal konformer tools/call Die Anfrage sieht auf der Leitung also wie folgt aus:

POST to the MCP endpoint
POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"get_weather","arguments":{"location":"Seattle, WA"},
 "_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}

Server können noch einen Schritt weiter gehen und spezifische Tool-Parameter für die Spiegelung festlegen, indem sie eine x-mcp-header Erweiterung im Schema des Parameters verwenden, wodurch Header mit dem Namen Mcp-Param-{Name}entstehen. Ein Server, der einen Region-Parameter annotiert, erhält Mcp-Param-Region: us-west1 zusätzlich zum Body – genau das Format, das ein Router benötigt, um eine Abfrage an das richtige regionale Backend zu senden, ohne den Payload lesen zu müssen.

Die Einschränkungen für diese Erweiterung sind streng und sollten bekannt sein, bevor Sie Ihr Design darauf ausrichten. Werte dürfen nicht leer sein, müssen der HTTP-Token-Syntax entsprechen, dürfen keine Steuerzeichen enthalten und müssen innerhalb des Schemas unabhängig von der Groß-/Kleinschreibung eindeutig sein. Es sind nur primitive Typen zulässig – String, Boolean und Integer, wobei number explizit ausgeschlossen ist. Zudem muss die annotierte Eigenschaft statisch von der Schema-Wurzel aus über eine Kette erreichbar sein, die ausschließlich aus properties Schlüsseln besteht: nicht über Array-Schlüsselwörter, nicht über oneOf, anyOf, allOfoder not, nicht durch Bedingungen und nicht durch $ref. Verschachtelte Objekte sind zulässig, solange jeder Schritt ein properties -Schlüssel ist. Eine Annotation an einer anderen Stelle macht die Tool-Definition ungültig, und ein konformer Client muss dieses Tool von tools/list ausschließen und eine Warnung protokollieren – damit eine fehlerhafte Definition nicht den Rest deaktiviert.

Werte, die nicht sicher als reines ASCII dargestellt werden können, werden innerhalb eines Sentinels Base64-kodiert: =?base64?...?=, und dieselbe Kodierung gilt für Mcp-Name. Ein nettes Detail: Ein reiner ASCII-Wert, der zufällig wie der Sentinel aussieht, muss ebenfalls kodiert werden, um die Mehrdeutigkeit zu beseitigen.

6. Warum eine Diskrepanz ein Fehler ist

Server, die den Request-Body verarbeiten, müssen Anfragen ablehnen, bei denen die Header-Werte nicht mit den entsprechenden Body-Werten übereinstimmen, und stattdessen 400 mit dem JSON-RPC-Fehler -32020zurückgeben. Die Spezifikation nennt den Grund explizit, und es handelt sich dabei eher um ein Sicherheitsargument als um eine Frage der Ordnung: Dies verhindert Schwachstellen, wenn verschiedene Komponenten im Netzwerk auf unterschiedliche Wahrheitsquellen vertrauen – etwa ein Load Balancer, der basierend auf dem Header-Wert routet, während der MCP-Server basierend auf dem Body-Wert ausführt.

Betrachten Sie dies als Bedrohungsmodell. Wenn ein Vermittler eine Entscheidung aufgrund eines Headers trifft und der Server auf Basis eines Body-Werts agiert, der etwas anderes besagt, kann ein Client, der diese unterschiedlich setzt, eine Situation mit gespaltenen Wahrheitsquellen herbeiführen – zum Beispiel wenn Routing oder Richtlinien anhand eines Wertes bewertet werden, während die Ausführung einen anderen verwendet. Die erforderliche serverseitige Validierung schließt diese Art von Diskrepanz für die aktuelle Revision aus, und kodierte Werte müssen vor dem Vergleich dekodiert werden.

7. Was dies für ein Gateway bedeutet

Es ist selten, dass ein Protokoll festlegt, was das Element in der Mitte tun soll. Da dies hier der Fall ist, ist die Zuordnung ungewöhnlich direkt.

Routing ohne Parsing. Mcp-Method und Mcp-Name bedeuten, dass ein Proxy allein anhand der Header zwischen einem Tool-Aufruf und einem Ressourcen-Lesevorgang unterscheiden kann – und weiß, welches Tool angesprochen wird. Das ist der Unterschied zwischen einer MCP-fähigen Ebene und einer, die jedes Payload deserialisieren muss, um eine Entscheidung zu treffen (MCP-Übersicht).

Tool-Identität für eine Autorisierungsebene offenlegen, ohne den Body zu parsen. Eine konforme tools/call -Anfrage enthält den Tool-Namen im Mcp-Name-Header. Dies gibt einem MCP-fähigen Vermittler eine protokolldefinierte Eingabe an die Hand, die er bei der Anwendung tool-spezifischer Richtlinien nutzen kann; Authentifizierung und Autorisierung müssen dennoch vom Gateway bzw. Server durchgesetzt werden, anstatt sie allein aus dem Header abzuleiten (Dokumentation zu MCP-Authentifizierung und Sicherheit).

Ratenbegrenzung nach Tool oder Mandant. Die Spezifikation nennt die Ratenbegrenzung nach Mandanten als beabsichtigte Nutzung gespiegelter Header durch Vermittler, wobei die Versionsprüfung als Sicherheitsbedingung dient (Ratenbegrenzung).

Beobachtung mit nützlichen Dimensionen. Methoden- und Toolnamen, die ohne Body-Parsing verfügbar sind, sind genau das, was Telemetrie pro Tool benötigt, und dies entspricht den Konventionen für Tool-Aufrufe, die sich in den Telemetriestandards abzeichnen (Dokumentation zu Analytik und Tracing).

Entfernung der MCP-Sitzungsaffinität aus der Transportschicht. Da Sitzungen auf Protokollebene entfernt wurden und Antwort-Streams auf einzelne Anfragen begrenzt sind, erfordert der MCP-Transport kein Sticky Routing oder einen gemeinsamen MCP-Sitzungsspeicher mehr. Anwendungen können weiterhin einen dauerhaften Status hinter expliziten Handles oder gemeinsamen Speichern verwalten, daher sollte „zustandsloser Transport“ nicht als „zustandslose Anwendung“ missverstanden werden. Hintergrundinformationen zur früheren Transportstruktur von 2025 finden Sie in unserem Vergleich zwischen stdio und streamfähigem HTTP; allgemeine Gateway-Verteilungsmuster werden unter Failover und Lastverteilungdiskutiert.

Eine Verpflichtung gilt in die andere Richtung und betrifft alles, was sich im Pfad befindet. Ein Vermittler, der einen Mcp-Param-{Name} -Header nicht erkennt, muss ihn weiterleiten und ansonsten ignorieren. Das Entfernen unbekannter Header – eine häufige Standardeinstellung bei gehärteten Proxys – führt dazu, dass konforme Server, die diese erwarten, nicht mehr funktionieren.

Wo ein Agent-Harness seinen Platz findet. Der Transport benötigt weiterhin einen Aufrufer, der entscheidet, wann ein Tool aufgerufen werden soll. TrueForge, das Open-Source-Agent-Harness von TrueFoundry, führt diese Ausführungsschleife über Modellaufrufe, Remote-MCP-Tools, Skills, Sandboxing, Genehmigungen, Kontextverwaltung und Sitzungsstatus hinweg aus. Sein MCP-Connector unterstützt Remote-Server mit Header-Authentifizierung oder OAuth, einschließlich einer Autorisierungspause im Chat, wenn ein Benutzer noch keinen Server verbunden hat. Das sorgt für eine saubere Trennung: TrueForge orchestriert den Agent-Schritt; streamfähiges HTTP definiert den Client-Server-Übertragungsvertrag; und ein TrueFoundry MCP-Gateway kann den Tool-Datenverkehr steuern, der gezielt darüber geleitet wird. Keine dieser Schichten ersetzt die anderen.

8. Eine bereitstellbare Architektur

Wenn Sie MCP-Server betreiben, validieren Sie Origin, authentifizieren Sie Verbindungen und binden Sie lokale Server konservativ, bevor Sie sich um das Feintuning des Streamings kümmern. Senden Sie dann X-Accel-Buffering: no bei SSE-Antworten und Keep-Alive-Kommentare bei langlebigen Streams; Pufferung und Leerlauf-Timeouts können sich als Anwendungslatenz oder Streaming-Fehler tarnen. Validieren Sie die Übereinstimmung von Header und Body, anstatt sich nur auf eines von beidem zu verlassen, und dekodieren Sie Sentinel-kodierte Werte vor dem Vergleich. Geben Sie für Datenverkehr von früheren Streamable-HTTP-Revisionen das spezifizierte Kompatibilitätsverhalten zurück – 405 bei GET und DELETE, und ignorieren Sie Session- und Event-ID-Header –, damit ältere Clients vorhersehbar fehlschlagen oder sich anpassen.

Wenn Sie einen Vermittler im Pfad betreiben, leiten Sie unbekannte Mcp-Param-* Header weiter, prüfen Sie die Protokollversion, bevor Sie gespiegelte Header als maßgeblich betrachten, und nutzen Sie die Vorteile, für die das Spiegeln entwickelt wurde: Routing, Richtlinieneingaben, Ratenbegrenzung und Telemetrie basierend auf Methode und Tool-Name, ohne jedes Payload deserialisieren zu müssen. Der Header liefert Metadaten; Ihre Identitäts- und Autorisierungsschicht entscheidet weiterhin, ob der Aufrufer die Aktion ausführen darf.

Wenn Sie einen Client schreiben, unterstützen Sie beide Antwort-Inhaltstypen, behandeln Sie SSE-Kommentarzeilen als ignorierbar und folgen Sie der Fallback-Sequenz – versuchen Sie eine moderne Anfrage, und bei einem 400 prüfen Sie den Body, bevor Sie Schlüsse ziehen, da moderne Server ebenfalls 400 bei nicht unterstützten Versionen und Header-Validierungsfehlern zurückgeben. Ein erkannter moderner Fehler bedeutet: erneut versuchen, anstatt auf eine ältere Version zurückzugreifen.

9. Was das Protokoll löst – und was nicht

Der Transport vom 28.07.2026 vereinfacht den Wire-Contract; er legt jedoch nicht die Geschäftslogik des Agenten fest. Er entfernt die Sitzungsaffinität auf MCP-Ebene, definiert die Funktionsweise von Streaming und Wiederholungsversuchen auf Anfrageebene und stellt Intermediären validierte Metadaten für Routing- und Richtlinienentscheidungen zur Verfügung. Er entscheidet nicht, welches Tool ein Agent aufrufen soll, erteilt dem Aufrufer keine Berechtigung zur Nutzung dieses Tools, definiert keine Genehmigungsrichtlinien, speichert keine Anwendungsinformationen und weist nicht nach, dass ein nachgelagerter Seiteneffekt durch das System of Record autorisiert wurde.

Diese Verantwortlichkeiten liegen bei angrenzenden Ebenen. Eine Agent-Runtime wie TrueForge steuert die Ausführungsschleife und kann MCP-Konnektoren, Genehmigungen, Kontext und Sitzungsstatus verwalten. Ein TrueFoundry MCP-Gateway kann Authentifizierung, Autorisierung, Tool-Zugriff und Beobachtbarkeit für den darüber geleiteten Datenverkehr zentralisieren. Der MCP-Server und die nachgelagerte Anwendung bleiben weiterhin für ihre eigene geschäftliche Autorisierung und deren Auswirkungen verantwortlich. Diese Grenzen explizit zu halten, ist sinnvoller, als einen saubereren Transport als vollständiges Sicherheitsmodell für Agenten zu betrachten.

Abschließend sei darauf hingewiesen, dass dieser Artikel eine Überarbeitung einer sich schnell entwickelnden Spezifikation beschreibt. Die hier genannten Anforderungsstufen basieren auf dem Text vom 28.07.2026; reale Clients und Server können bei den Revisionen hinterherhinken, und die Spezifikation ist gegenüber jeder Zusammenfassung maßgeblich. Dieser Beitrag erhebt zudem nicht den Anspruch, dass eine bestimmte bereitgestellte TrueFoundry Gateway-Version intern jeden gespiegelten Header vom 28.07.2026 verarbeitet.

Referenzen

• Model Context Protocol – Spezifikation für streamfähigen HTTP-Transport (28.07.2026), die Quelle für die hier beschriebenen Transportmechanismen, Sicherheitsgrundlagen, Anforderungsmetadaten, Validierungs- und Kompatibilitätsregeln.
• Model Context Protocol – Changelog vom 28.07.2026, sowie die Transport-Revision vom 25.11.2025 für die vorherige Struktur.
• Model Context Protocol – Anfragen mit mehreren Roundtrips und Abonnements.
• TrueFoundry — stdio vs. Streamable HTTP — früherer Transportkontext; MCP-Authentifizierung und -Sicherheit; Ratenbegrenzung; Analytik.
• TrueForge — Open-Source-Agenten-Harness und MCP-Server-Einrichtung, Dokumentation von Remote-MCP-Connectors mit Header-Auth oder OAuth, In-Chat-Autorisierung, Genehmigungen, Kontextverwaltung und persistenten Sitzungen.

Mechaniken, Anforderungsstufen, Headernamen, Fehlercodes, Kompatibilitätsregeln und MRTR-Zustandssicherheitsanforderungen sind aus dem verlinkten Spezifikationstext vom 28.07.2026 paraphrasiert; das Beispiel für die Anfrage ist der eigenen Illustration der Spezifikation nachempfunden. Das Remote-HTTP-Wire-Design von MCP hat sich über drei Epochen hinweg wesentlich verändert, und die Spezifikation ist maßgeblich gegenüber dieser Zusammenfassung. Die Produktversprechen von TrueFoundry beschränken sich auf die auf den verlinkten aktuellen Seiten dokumentierten Funktionen; dieser Beitrag behauptet nicht, dass eine bestimmte bereitgestellte Gateway-Version intern jeden gespiegelten Header vom 28.07.2026 verwendet.

‍