sgcWebSockets 2026.8: QUIC, HTTP/3, statisches OpenSSL und eine TLS-Überarbeitung | eSeGeCe Blog

sgcWebSockets 2026.8: QUIC, HTTP/3, statisches OpenSSL und eine TLS-Überarbeitung

· Versionen

sgcWebSockets 2026.8 ist das größte Release des Jahres. Es gibt vier neue Transportkomponenten, QUIC und HTTP/3 auf Client- und Serverseite, OpenSSL lässt sich jetzt in Ihre ausführbare Datei linken, sodass eine TLS-Anwendung ohne eine einzige DLL ausgeliefert wird, und sgcHTML wächst um mehr als dreißig Komponenten, erhält einen WebBroker- und DataSnap-Dispatcher und passt sich an ein Telefondisplay an.

Darunter wurde die SChannel-TLS-Schicht auseinandergenommen und neu aufgebaut. Wenn Sie den Windows-TLS-Stack verwenden, ist das dieses Release zum Installieren: TLSOptions.Version wurde stillschweigend ignoriert, ein widerrufenes Zertifikat wurde akzeptiert, eine TLS 1.3-Verbindung kam nie zustande, und eine Neuaushandlung ersetzte das Zertifikat ganz ohne Prüfung. All das ist behoben, und Sperrprüfung, eine Mindestversion sowie die Prüfung von Client-Zertifikaten auf dem Server stehen jetzt zur Verfügung. Der Rest dieses Beitrags ist die geführte Tour, und jeder Abschnitt verlinkt auf den Artikel, der die Funktion ausführlich behandelt.

QUIC und HTTP/3

Vier neue Komponenten bringen QUIC (RFC 9000) und HTTP/3 (RFC 9114) nach Delphi und C++ Builder: TsgcQUICClient, TsgcQUICServer, TsgcHTTP3Client und TsgcHTTP3Server. Sie laufen auf der nativen QUIC-Engine von OpenSSL 3.5, es muss also kein Stack von Drittanbietern ausgeliefert werden, und Sie erhalten TLS 1.3 direkt in den Handshake eingebettet, gemultiplexte Streams ohne Head-of-Line-Blocking, 0-RTT-Wiederaufnahme und Verbindungsmigration, wenn der Client das Netzwerk wechselt.

uses
  sgcQUIC_Client;

var
  oClient: TsgcQUICClient;
begin
  oClient := TsgcQUICClient.Create(nil);
  oClient.Host := 'www.example.com';
  oClient.Port := 443;
  oClient.OnQUICConnect    := OnQUICConnect;
  oClient.OnQUICStreamData := OnQUICStreamData;

  oClient.Active := True;          // TLS 1.3 handshake in a single flight
  oClient.WriteData('ping');       // send bytes on a QUIC stream
end;

Der HTTP/3-Client beherrscht jedes HTTP-Verb, führt QPACK-Header-Komprimierung durch, arbeitet blockierend oder asynchron, findet einen HTTP/3-Endpunkt über Alt-Svc und verarbeitet Server-Push.

uses
  sgcHTTP3_Client;

var
  oClient: TsgcHTTP3Client;
  vBody: string;
begin
  oClient := TsgcHTTP3Client.Create(nil);
  oClient.OnResponse := OnResponse;
  oClient.OnAltSvc   := OnAltSvc;

  oClient.Connect('www.example.com', 443);
  vBody := oClient.Get('https://www.example.com/');
end;

Beide benötigen das sgcQUIC-Paket mit sgcWebSockets Enterprise. Mehr dazu: QUIC Client- und Server-Komponenten und HTTP/3 Client- und Server-Komponenten.

OpenSSL in der ausführbaren Datei

libcrypto und libssl neben der Anwendung auszuliefern war schon immer der unangenehmste Teil bei der Auslieferung eines TLS-Clients. Ab 2026.8 kann die Bibliothek OpenSSL 3.5.7 statisch linken: Fügen Sie der uses-Klausel Ihres Projekts eine Unit hinzu und die DLLs sind verschwunden. Entfernen Sie die Unit und die DLLs werden wieder genau wie zuvor geladen, die Entscheidung ist also in beide Richtungen eine Änderung von einer Zeile.

uses
  sgcWebSocket, sgcWebSocket_Classes,
  sgcIdSSLOpenSSL_Static;

Das gilt für Clients und Server, 32 und 64 Bit, ab Delphi XE2. Mehr dazu: Statisches OpenSSL-Linken, keine DLLs mehr.

sgcHTML: WebBroker, DataSnap und dreißig neue Komponenten

sgcHTML-Seiten sind nicht mehr an den sgcWebSockets-Server gebunden. Eine neue Dispatcher-Komponente liefert sie aus jeder WebBroker-Anwendung aus, standalone, ISAPI, Apache oder CGI, und aus DataSnap-Servern, wo die Bridge Live-WebSocket-Updates auf demselben Port wie Ihre REST-Endpunkte ergänzt.

uses
  Web.HTTPApp, sgcHTMX_Engine_Server_WebBroker, sgcHTMX_Router;

// Any WebBroker host: the engine's Owner is the web module,
// so the standard WebBroker dispatcher calls it automatically
FEngine := TsgcHTMX_Engine_Server_WebBroker.Create(WebModule1);
FEngine.Router := FRouter;   // your htmx routes and the page

Der Komponentensatz ist in diesem Release erheblich gewachsen, und alles wird weiterhin auf dem Server gezeichnet, ohne clientseitige Bibliothek, die geladen werden müsste:

Seiten passen sich jetzt auch an die Bildschirmgröße an. Auf einem Telefon klappt das Seitenmenü hinter einer Schaltfläche weg und der Inhalt nutzt die volle Breite, auf einem Desktop ändert sich nichts. Setzen Sie die neue Eigenschaft Responsive auf False, um das bisherige feste Layout zu erhalten. Mehr dazu: sgcHTML auf WebBroker und DataSnap.

Die SChannel-TLS-Überarbeitung

SChannel ist der Windows-TLS-Stack, derjenige, den Sie bekommen, ohne überhaupt OpenSSL auszuliefern. Er hatte eine Reihe von Problemen, die von außen unsichtbar waren, also die schlimmste Sorte. TLSOptions.Version wurde unter Windows 11 und Windows Server 2022 überhaupt nicht gelesen, die Anforderung von TLS 1.3 unter Windows 10 lieferte stillschweigend TLS 1.2, und blieb die Version undefiniert, wurden SSL 3.0, TLS 1.0 und TLS 1.1 wieder eingeschaltet. Ein widerrufenes Serverzertifikat wurde selbst mit VerifyCertificate auf True akzeptiert, weil die Kette aufgebaut wurde, ohne einen Sperrstatus abzufragen. Nach einer Neuaushandlung wurde ein neues Zertifikat ohne jede Prüfung der Kette oder des Hostnamens akzeptiert. Die Verbindungen, die Indy nebenbei öffnet, eine HTTP-Weiterleitung auf einen anderen Host oder ein FTP-Datenkanal, kamen mit einer leeren Konfiguration zurück, liefen also mit ausgeschalteter Prüfung, und nichts meldete es.

All das ist behoben, die ausgehandelte Version wird jetzt geprüft, wenn der Handshake abgeschlossen ist, und mit dieser Arbeit kamen drei neue Optionsgruppen: Sperrprüfung, eine Mindestversion und Windows Strong Crypto.

// client
oClient.TLSOptions.Version     := tls1_3;   // highest version to use
oClient.TLSOptions.SChannel_Options.VersionMin := tls1_2;   // lowest accepted
oClient.TLSOptions.SChannel_Options.UseStrongCrypto := True;
oClient.TLSOptions.SChannel_Options.Revocation.Check   := scrcChainExcludeRoot;
oClient.TLSOptions.SChannel_Options.Revocation.Timeout := 5000;  // ms

// or all of it in one line
oClient.TLSOptions.Preset := tlspSecureDefaults;

Die Standardwerte der Sperrprüfung sind bewusst nachsichtig: IgnoreRevocationOffline und IgnoreNoRevocationCheck sind True, das Einschalten der Prüfung kann also keine Verbindung zerstören, die bisher funktioniert hat, und der Timeout begrenzt den Abruf von CRL und OCSP, sodass ein nicht erreichbarer Responder den Handshake nicht blockieren kann. Ein tatsächlich widerrufenes Zertifikat wird immer abgelehnt.

Auf der Serverseite kann SChannel jetzt vom Client ein Zertifikat anfordern, was zuvor nie geschah. Das Client-Zertifikat durchläuft dieselben Prüfungen, die ein Client auf ein Serverzertifikat anwendet, die Kette, die Gültigkeitsdaten und das Ereignis OnSChannelVerifyPeer, ohne die Prüfung des Hostnamens.

oServer.SSLOptions.VerifyCertificate := True;
oServer.SSLOptions.VerifyCertificate_Options.FailIfNoCertificate := True;

Zwei weitere Korrekturen gehören hierher. Ein Client mit SChannel bemerkte nie, dass die Verbindung weg war, wenn die Gegenseite sie ohne Abschlussmeldung fallen ließ, wie es beim Neustart eines Proxys passiert, also wurde OnDisconnect nie ausgelöst und der WatchDog lief nie. Und eine TLS 1.3-Verbindung kam überhaupt nie zustande, weil das Session-Ticket, das der Server direkt nach dem Handshake sendet, den Client auf Daten warten ließ, die der Server bereits gesendet hatte. Der Handshake berücksichtigt jetzt ConnectTimeout, statt nur den TCP-Connect abzudecken, und vor dem Schließen wird eine Abschlussmeldung gesendet, bei SChannel-, Apple- und Android-Verbindungen gleichermaßen.

Serverlimits und die IOCP- / EPOLL-Engines

Server haben eine Reihe von Limits erhalten, die früher unbegrenzt waren. Der WebSocket-Server akzeptiert standardmäßig 10.000 gleichzeitige Verbindungen statt einer unbegrenzten Anzahl und begrenzt, wie viele Control-Frames ein Client pro Sekunde senden darf (100), sodass er nicht mit Pings überflutet werden kann. Der HTTP/2-Server hat MaxRequestSize bekommen und die DTLS-Komponente MaxConnections, HandshakeTimeout und IdleTimeout, sodass eine Flut einzelner Pakete von erfundenen Adressen den Speicher des Servers nicht mehr füllt. Jedes davon lässt sich erhöhen oder für das bisherige Verhalten auf 0 setzen.

Die Hochleistungs-Engines haben eine lange Liste von Reparaturen erhalten: Speicher- und Handle-Lecks sowie Abstürze auf mehreren Aufräumpfaden, ein Client, der die Leitung direkt nach dem Akzeptieren fallen ließ, eine Verbindung, die zweimal freigegeben wurde, wenn der Server mitten im Aufräumen gestoppt wurde, ein Use-after-free bei aktivierten Worker-Threads und ein Puffer, der bei jeder verarbeiteten Nachricht verloren ging. HTTP-Keep-Alive funktionierte überhaupt nicht, die Verbindung wurde also nach jeder Anfrage geschlossen und der Server füllte sich mit Sockets im Zustand TIME_WAIT. Unter Linux verlor jede HTTP-Anfrage Teile der geparsten Anfrage, und alle Worker teilten sich eine einzige Verbindungswarteschlange, sodass ein oder zwei Threads fast die gesamte Arbeit erledigten.

Zwei neue Optionen runden das Ganze ab, beide standardmäßig aus: Keep-Alive-Probes und ein Idle-Timeout, sodass sich halboffene Sockets nicht mehr ansammeln, und eine Round-Robin-Verteilung neuer Verbindungen auf die Worker-Threads.

Server.IOHandlerOptions.IOHandlerType := iohEPOLL;
Server.IOHandlerOptions.EPOLL.TCPKeepAlive.Enabled  := True;
Server.IOHandlerOptions.EPOLL.TCPKeepAlive.Time     := 60;  // seconds idle before probing
Server.IOHandlerOptions.EPOLL.TCPKeepAlive.Interval := 10;  // seconds between probes
Server.IOHandlerOptions.KeepAliveTimeout            := 120; // seconds

Mehr dazu: TCPKeepAlive und KeepAliveTimeout für IOCP- und EPOLL-Server. Dank an Andrea für den Patch, auf dem mehrere der Engine-Korrekturen beruhen.

Protokolle: STOMP, MQTT, AMQP und HTTP/2

STOMP hat die meiste Arbeit erhalten. Ein geordnetes Disconnect wartet jetzt, bis der Broker es mit einer Quittung bestätigt, sodass beim Schließen nichts verloren geht. Nachrichten werden genau so zugestellt, wie der Broker sie gesendet hat, wobei content-length zum Lesen des Bodys verwendet wird, sodass dieser Zeilenumbrüche und binäre Nullen enthalten darf. Frames, die zu mehreren in einer WebSocket-Nachricht gepackt sind, werden alle verarbeitet, ein über zwei Nachrichten verteilter Frame wird wieder zusammengesetzt, und binäre Frames werden nicht mehr ignoriert. ACK und NACK senden die Header, die die ausgehandelte Version verlangt, und Heartbeats starten erst, nachdem der Server die Verbindung bestätigt hat.

oSTOMP.DisconnectTimeout := 10000;   // ms to wait for the receipt, 0 = return at once
oSTOMP.ACKEx(vMessageId, vSubscriptionId);
ShowMessage('STOMP ' + oSTOMP.NegotiatedVersion);

MQTT baut keine Pakete mehr, die Broker ablehnen, etwa ein CONNECT mit Benutzernamen und ohne Passwort oder ein MQTT 5-Paket mit einem größeren Block an Properties, und der MQTT 5-Client liest nicht mehr über das Ende eines Pakets hinaus: Ein abgeschnittenes Paket übergab der Anwendung früher das, was im Speicher folgte, als Property-Werte. Er berücksichtigt jetzt, was der Broker ihm mitteilt, vom im CONNACK zurückgegebenen Keep Alive bis zu einer Nachricht, die nur mit einem Topic Alias eintrifft. Der Veröffentlichungspfad für QoS 2 sendet die korrekte Folgebestätigung, verwirft eine vom Broker abgelehnte Nachricht, statt sie ewig erneut zu senden, und wiederholt nach einem sinnvollen Zeitplan.

Der AMQP 1.0-Client ist jetzt gegen einen fehlerhaften Broker geschützt: Frames, die in kleinen Stücken eintreffen, eine ungültige Header-Größe, zu tief verschachtelte Nachrichten, eine kleine Nachricht, die so konstruiert ist, dass sie sich zu einer riesigen Speichermenge aufbläht. Die maximale Frame-Größe für AMQP 0.9.1 und 1.0 beträgt standardmäßig 1 MB statt praktisch unbegrenzt. Die HTTP/2-Header-Komprimierung ist gegen manipulierte Header geschützt, die Verbindung lehnt einen DATA-Frame für einen nie geöffneten Stream ab, ebenso eine Flut von PRIORITY-Frames, die Wiederverwendung von Stream-Nummern und Fluten leerer Continuations, und der Server lehnt Header-Namen und -Werte mit Zeilenumbrüchen oder Nullen ab, was Request Smuggling verhindert. Das Speicherwachstum durch zurückgesetzte Streams und die Meldung "CONCURRENT STREAM limit has been exceeded" nach etwa 100 Anfragen sind beide behoben.

MCP-Server

Tools können jetzt ein vollständiges JSON Schema für ihre Eingabe bereitstellen und dabei Arrays mit Items, Enums, Integer- und Nullable-Typen, verschachtelte Objekte und additionalProperties deklarieren, was manche MCP-Clients verlangen und andernfalls ablehnen würden. Der Server stellt außerdem die Metadaten des Protokolls 2025-11-25 bereit: die Annotation readOnlyHint und den Annotationstitel, Tool-Icons, Servertitel, Website und Icons sowie die Deklaration der Task-Unterstützung in tools/list.

Zwei Korrekturen sind wichtig, wenn Sie bereits einen betreiben. Der Server schrieb seine interne Verbindungs-ID als Nachricht in den Event-Stream, den ein Client mit GET öffnet, was Clients wie VS Code GitHub Copilot als "Failed to parse message" meldeten. Und die Origin-Prüfung lief nur, wenn die Anfrage einen Header mitbrachte, den Browser nie senden, sie lief also nie für den Fall, den sie verhindern sollte: Eine vom Benutzer besuchte Webseite konnte einen MCP-Server auf seinem eigenen Rechner erreichen, dessen Tools auflisten, sie ausführen und die Ergebnisse lesen. Der Origin wird jetzt bei jeder Anfrage geprüft, einschließlich der vorbereitenden Prüfung des Browsers.

MCPServer.MCPOptions.HTTPStreamable.AllowedOrigins.Add('https://*.example.com');

Krypto-Börsen

Zwei Kundenmeldungen haben das meiste davon angestoßen. Eine Anfrage, die mit einem HTTP-Fehlerstatus fehlschlägt, meldet jetzt die Header, mit denen der Server geantwortet hat, sodass Retry-After bei einer 429 oder die Rate-Limit-Zähler, die Börsen zurückgeben, endlich gelesen werden können. Die fertigen API-Clients lösen EsgcHTTPAPIProtocolException aus, die von der zuvor ausgelösten Exception abgeleitet ist, sodass bestehende Handler weiterhin funktionieren.

try
  vResponse := oBinance.GetAggregateTrades('BTCUSDT');
except
  on E: EsgcHTTPAPIProtocolException do
  begin
    if E.ErrorCode = 429 then
      Sleep(E.RetryAfterMs);
    vWeight := E.GetHeader('X-MBX-USED-WEIGHT-1M');
    // E.ResponseHeaders holds the complete list
  end;
end;

Jeder Börsen-Client sendete nach einer Wiederverbindung seine gesamte Abonnementliste in einem Schwung erneut, auf einer wenige Millisekunden alten Verbindung, sodass eine Börse, die Nachrichten pro Sekunde begrenzt, sie sofort schloss und der Zyklus von vorn begann. Diese Wiederholung ist jetzt zeitlich getaktet und wird bei Binance als kombinierte Frames gesendet. Es gibt außerdem eine neue clientseitige Drosselung für die Nachrichten, die Sie senden.

oBinance.Throttle.Enabled     := True;
oBinance.Throttle.MaxMessages := 4;      // per window
oBinance.Throttle.IntervalMs  := 1000;
// paced reconnect replay is on by default:
// oBinance.Throttle.PaceResubscribe := False;  restores the old burst

// subscribe a whole watchlist with ONE frame
oBinance.SubscribeStreams(['btcusdt@trade', 'ethusdt@trade', 'bnbusdt@trade']);

Binance hat die listenKey-Endpunkte abgeschaltet, auf denen der Spot-User-Data-Stream aufgebaut war, Konto-, Order- und Guthaben-Updates kommen daher jetzt von der Binance WebSocket API, über eine zweite Verbindung, welche die Komponente selbst öffnet und nach einer Wiederverbindung erneuert. Die Ereignisse treffen in derselben Form ein, Ihre Handler funktionieren also weiterhin, aber das neue Abonnement ist signiert: Binance.ApiSecret muss jetzt zusätzlich zu Binance.ApiKey gesetzt sein. Binance.us und Futures verwenden weiterhin einen listenKey. Die Marktdaten der USD-M Futures werden jetzt von zwei Adressen ausgeliefert, ausgewählt über die neue Eigenschaft Binance.FuturesStreamEndpoint (bfsePublic als Standard, bfseMarket für Aggregate-Trades-, Mark-Price-, Kline- und Liquidation-Streams).

Ebenfalls behoben: OKX-Preise und -Größen wurden vor dem Senden auf fünf Nachkommastellen gerundet, sodass eine Order auf einem Instrument mit feinerer Tick-Größe nicht die Order war, die Sie aufgeben wollten, und ein Wert unter 0,00001 wurde als Null gesendet. Die Keepalives von OKX und KuCoin senden jetzt den Text-Ping, den die jeweilige Börse verlangt, statt eines WebSocket-Pings, und verbinden sich neu, wenn kein Pong zurückkommt. Mehr dazu: Binance-Rate-Limits: Bündelung, Taktung und lesbare 429er.

zlib 1.3.1 und eine Stückliste

Das mitgelieferte zlib wechselt von 1.2.12 auf 1.3.1, was CVE-2022-37434 behebt, ein Heap-Over-Read in inflate. Die gelinkten Objekte wurden für Delphi 7 bis Delphi 13, 32 und 64 Bit, neu erstellt und auf jedem Compiler verifiziert. Eine Nebenkorrektur: Unter Delphi 10 Seattle 64 Bit wurden die zlib-Objekte überhaupt nicht gelinkt, dort wurden die 32-Bit-Objekte gewählt und die Kompilierung schlug fehl.

Jedes Setup installiert jetzt außerdem sbom.cdx.json, eine CycloneDX-Software-Stückliste, welche die Komponenten auflistet, aus denen die Bibliothek gebaut ist, mit ihren Versionen und Lizenzen. Enterprise und All-Access nennen die Versionen des angepassten Indy und dessen zlib, Core, Standard und Professional halten fest, dass Indy dasjenige ist, das mit Delphi oder C++ Builder geliefert wird. Sie wird pro Edition beim Erstellen des Installers erzeugt und passt daher immer zu dem, was Sie installiert haben. Mehr dazu: zlib 1.3.1 in sgcWebSockets und sgcOpenAPI und sgcWebSockets installiert jetzt seine eigene SBOM.

Sicherheitskorrekturen

Über TLS hinaus schließt dieses Release eine ganze Reihe von Lücken. Lesen Sie die Liste, und wenn eine dieser Komponenten in Ihrer Anwendung steckt, aktualisieren Sie.

Noch eine, die leicht zu übersehen ist: Die meisten TLS-Optionen gingen verloren, wenn sie von einer Komponente auf eine andere kopiert wurden. Nur der IO-Handler, die ALPN-Protokolle und die OpenSSL-Optionen wurden kopiert, die Zertifikatsdateien, das Passwort, das Wurzelzertifikat, die TLS-Version und VerifyCertificate blieben also leer, und eine so eingerichtete Komponente prüfte am Ende gar nichts.

Kleinere Ergänzungen

Ebenfalls neu rund um dieses Release

Zwei Bestandteile, die mit der Bibliothek ausgeliefert werden, haben diesen Monat eigene Artikel bekommen: die REST-Server-Komponenten, ein HTTP-Server für REST-APIs mit CORS, Metriken, Health-Endpunkten, Mandantenfähigkeit und einem OpenAPI-Plugin, das aus einer einzigen Spezifikationsdatei Routing, Validierung, Sicherheit und Swagger UI erzeugt, und sgcProtoBuf, der Codegenerator, der .proto-Dateien in Delphi-Units verwandelt. Mehr dazu: TsgcHTTPRESTServer: die neue REST-Server-Komponente, REST-Server + OpenAPI, Benutzer, Mandantenfähigkeit und Metriken und sgcProtoBuf: Von .proto-Dateien zu Delphi-Units.

Die .NET-Edition

sgcWebSockets .NET 2026.8 enthält die gemeinsame Hälfte dieses Releases. Die SChannel-Arbeit ist vollständig dabei, die ignorierte Version, die bei geklonten Verbindungen verlorenen Einstellungen, die ungeprüfte Neuaushandlung, die TLS 1.3-Verbindung, die nie zustande kam, die unbemerkt abgebrochene Verbindung, der unbegrenzte Handshake und das Startup-Race, dazu die Abschlussmeldung vor dem Schließen und die Prüfung von Client-Zertifikaten auf dem Server. Die IOCP- und EPOLL-Korrekturen, die Validierung von WebSocket-Handshake und -Frames, die Härtung von MQTT, STOMP, AMQP und HTTP/2, die Sicherheitskorrekturen für OAuth2, WebAuthn, MCP und das Files-Protokoll sowie die Änderungen an den Börsen (der Binance-Spot-User-Data-Stream, die getaktete Wiederholung nach einer Wiederverbindung, die Keepalives von OKX und KuCoin) sind ebenfalls enthalten. Das geordnete STOMP-Disconnect mit seiner Quittung und die Begrenzung der Control-Frames im WebSocket-Server sind dort ebenfalls neu.

Aktualisierung

2026.8 ist ein Drop-in-Upgrade für bestehende 2026.x-Projekte, mit zwei Dingen, die Sie vor dem Bauen wissen sollten. Der Binance-Spot-User-Data-Stream signiert jetzt sein Abonnement, Binance.ApiSecret muss also zusätzlich zu Binance.ApiKey gesetzt werden. Und der WebSocket-Server akzeptiert jetzt standardmäßig 10.000 gleichzeitige Verbindungen statt einer unbegrenzten Anzahl, erhöhen Sie also MaxConnections oder setzen Sie es auf 0, wenn Sie darüber liegen.

Alles andere bleibt aus, bis Sie es anfordern: Sperrprüfung, die Mindestversion, Strong Crypto, die Prüfung von Client-Zertifikaten, Keep-Alive auf den IOCP- und EPOLL-Engines, die Nachrichtendrosselung und die Liste der erlaubten MCP-Origins entsprechen standardmäßig alle dem bisherigen Verhalten.

Kunden mit einem aktiven Abonnement können den neuen Build im Kundenbereich herunterladen oder unter esegece.com/products/websockets/download.

Fragen, Feedback oder Hilfe bei der Migration? Nehmen Sie Kontakt auf. Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.