Version 2026.9.0 : sgcWebSockets, sgcSign, sgcIndy et sgcOpenAPI

· Versions
Version 2026.9.0 des bibliothèques de composants eSeGeCe pour Delphi, C++ Builder et .NET

2026.9.0 sort d'un coup pour tous les produits : sgcWebSockets, sgcWebSockets .NET, sgcSign, sgcIndy et sgcOpenAPI. C'est la plus grande version de l'année. Deux packages entièrement nouveaux rejoignent sgcWebSockets, les moteurs serveur ont été retravaillés autour d'un problème qui faisait perdre des requêtes depuis longtemps, et la bibliothèque de signature a appris à vérifier une signature par rapport à autre chose qu'elle-même.

Cet article parcourt ce qui compte dans chaque produit, avec le code Delphi là où cela aide. Tout se trouve dans le changelog, et les points qui modifient le comportement existant sont regroupés vers la fin pour que vous puissiez les lire avant de mettre à jour.

Toute la version en moins de quatre minutes. Également sur YouTube.

ProduitNouveautésCorrectionsIncompatibilités
sgcWebSockets255622
sgcSign257021
sgcOpenAPI9255
sgcWebSockets .NET52410
sgcIndy050

sgcWebSockets 2026.9.0

sgcWebRTC, un moteur multimédia WebRTC natif

Le nouveau package sgcWebRTC transforme TsgcRTCPeerConnection en un point de terminaison WebRTC complet. Appels audio et vidéo, partage d'écran et canaux de données SCTP, le tout en Pascal, sans navigateur, sans contrôle WebView et sans bibliothèque multimédia externe. Il fonctionne sous Windows, Linux, macOS, iOS et Android, et le pair à l'autre bout peut être un navigateur, car le SDP qu'il produit et consomme est le vrai.

L'échange d'offre et de réponse suit la forme définie par le W3C, donc CreateOffer, CreateAnswer, SetLocalDescription, SetRemoteDescription et AddIceCandidate font ce que leur nom indique. Vous transportez le SDP sur le canal de signalisation dont vous disposez déjà, qui peut être un serveur WebSocket construit avec la même bibliothèque.

uses
  sgcP2P;

var
  oRTC: TsgcRTCPeerConnection;
begin
  oRTC := TsgcRTCPeerConnection.Create(nil);
  oRTC.RTCOptions.ICEServers.AddURL('stun:stun.l.google.com:19302');
  oRTC.OnLocalDescription      := OnLocalDescriptionHandler;
  oRTC.OnICECandidate          := OnICECandidateHandler;
  oRTC.OnConnectionStateChange := OnConnectionStateChangeHandler;
  oRTC.OnDataChannel           := OnDataChannelHandler;

  oRTC.CreateDataChannel('chat');   // forces RTCOptions.DTLS on
  oRTC.CreateOffer;                 // gathers ICE candidates, builds the SDP offer
end;

procedure TForm1.OnLocalDescriptionHandler(Sender: TObject;
  const aType, aSDP: string);
begin
  // send aType + aSDP to the remote peer over your own signalling channel
end;

Le média fonctionne de la même façon. AddTrack attache une piste audio Opus ou G.711, ou une piste vidéo VP8, H.264 ou Motion JPEG, SendPCM et SendVideoFrame y injectent le média capturé, et OnAudio et OnVideoFrame vous remettent la piste distante décodée.

Les anciens replis de l'ère du navigateur ont pris le chemin inverse. La prise en charge du protocole AppRTC et de l'API RTCMultiConnection a été supprimée, tout comme le repli Flash, arrivé en fin de vie en 2020. Voyez les notes de mise à jour à la fin.

sgcCrypto, la cryptographie sans OpenSSL

Le deuxième nouveau package est sgcCrypto, une implémentation en Pascal pur des primitives que la plupart des applications utilisent réellement. Chiffrement authentifié AES et ChaCha20/XChaCha20-Poly1305, SHA-2 et SHA-3, Argon2, scrypt et HKDF pour les mots de passe et la dérivation de clés, Ed25519, Ed448, X25519, X448 et secp256k1, génération de clés RSA, génération de certificats X.509 et de CSR, et les algorithmes post-quantiques ML-KEM, ML-DSA et SLH-DSA.

Chaque primitive est une simple fonction. Il n'y a pas d'objet de contexte à créer, configurer et libérer, ni de DLL à livrer à côté de l'exécutable.

uses
  sgcCrypto_Random, sgcCrypto_AES, sgcCrypto_Keccak, sgcCrypto_Ed25519,
  sgcCrypto_MLKEM;

var
  vKey, vIV, vPlain, vAAD, vTag, vCipher: TBytes;
  vDigest, vSeed, vSignature, vMessage: TBytes;
  vPublicKey, vPrivateKey, vSharedSecret, vCiphertext: TBytes;
begin
  // AES-256-GCM: authenticated encryption in one call
  vKey    := sgcRandomBytes(32);
  vIV     := sgcRandomBytes(12);
  vPlain  := TEncoding.UTF8.GetBytes('confidential payload');
  vCipher := sgcAES_GCM_Encrypt(vKey, vIV, vPlain, vAAD, vTag);

  // SHA-3-256, one call, no context object to manage
  vDigest := sgcSHA3_256(vPlain);

  // Ed25519: sign, then verify
  vSeed      := sgcRandomBytes(32);
  vMessage   := TEncoding.UTF8.GetBytes('sign me');
  vSignature := sgcEd25519_Sign(vSeed, vMessage);

  // ML-KEM-768: post-quantum key encapsulation (FIPS 203)
  sgcMLKEM_GenerateKeyPair(mlkem768, vPublicKey, vPrivateKey);
  sgcMLKEM_Encapsulate(mlkem768, vPublicKey, vCiphertext, vSharedSecret);
end;

Cinq applications sgcHTML complètes

sgcHTML gagne quatre composants et cinq démos. Les composants sont CameraScanner, un panneau caméra en direct qui lit les codes-barres et les QR codes avec le scanner intégré au navigateur et propose toujours une saisie manuelle en repli, plus NumPad, CommandPalette et EmptyState.

Les cinq démos ne sont pas des extraits. Chacune est une application entière avec authentification, base de données et rapports imprimables, et elles se trouvent sous Demos\60.HTML\01.RunTime : gestion d'entrepôt, point de vente, portail de reporting, plan de contrôle SaaS multi-locataires et répartition d'interventions sur le terrain.

Il y a aussi une nouvelle rubrique d'aide, Runtime vs Design-Time, avec des démos qui montrent comment construire la même page en déposant des composants sur une fiche VCL au lieu de la composer en code.

L'adresse réelle du client derrière un proxy inverse

Un serveur derrière nginx, Apache ou un répartiteur de charge cloud voit l'adresse du proxy sur chaque connexion, ce qui veut dire que la liste noire, la liste blanche, GeoIP et vos propres règles regardaient tous le mauvais client. Les nouveaux réglages ForwardedHeaders de TsgcWebSocketFirewall récupèrent l'adresse transmise par le proxy.

La conception est délibérément méfiante. L'adresse contenue dans X-Forwarded-For ou X-Real-IP n'est crue que si la connexion elle-même arrive d'une adresse listée dans TrustedProxies, de sorte qu'un client ne peut pas en inventer une, et la chaîne est lue depuis la droite, au-delà du nombre de proxies indiqué dans TrustedHops, parce que l'entrée la plus à gauche est celle fournie par le client. La résolution est effectuée à chaque requête, puisqu'un proxy réutilise une même connexion pour des requêtes provenant d'appelants différents.

uses
  sgcWebSocket;

begin
  oFirewall.ForwardedHeaders.Enabled := True;
  oFirewall.ForwardedHeaders.TrustedProxies.Add('10.0.0.0/8');
  oFirewall.ForwardedHeaders.TrustedProxies.Add('::1');
  oFirewall.ForwardedHeaders.TrustedHops := 1;

  oServer.Firewall := oFirewall;
end;

procedure TForm1.OnServerConnectHandler(Connection: TsgcWSConnection);
begin
  // Connection.IP is now the end client
  // Connection.PeerIP is still the proxy that opened the socket
end;

Une fois résolue, cette adresse est celle que voient chaque entrée de liste noire, chaque règle personnalisée, chaque événement et votre propre code de gestionnaire. Les réglages se comportent de la même façon sur le serveur http.sys que sur celui d'Indy, et la même fonctionnalité arrive dans le sgcSign Server sous le nom server.firewall.forwarded_headers.

Une contre-pression que vous pouvez mesurer

Écrire vers un client lent plus vite qu'il ne lit fait grossir la file de sortie jusqu'à ce que quelque chose cède. Il n'y avait aucun moyen de le voir depuis l'intérieur de l'application, si bien que les relais finissaient par faire un échange en arrêt et attente sur le réseau, juste pour rester prudents.

Deux ajouts remplacent cela. PendingCount sur TsgcWSConnection indique combien de messages sont encore en file d'attente pour cette connexion, tous niveaux de priorité confondus, et sa lecture n'alloue rien, on peut donc l'interroger en boucle. OnQueueDrained se déclenche quand la file d'une connexion passe de l'état « elle contient des messages » à l'état « elle est vide », sur le thread de la connexion, juste après la vidange et avant la lecture suivante, de sorte qu'un crédit peut être accordé sans le moindre délai.

procedure TForm1.OnQueueDrainedHandler(Connection: TsgcWSConnection);
begin
  // raised on the connection thread: do not touch the user interface here
  SendNextBatch(Connection);
end;

procedure TForm1.SendIfRoom(Connection: TsgcWSConnection; const aText: string);
begin
  if Connection.PendingCount < 100 then
    Connection.WriteData(aText);
end;

Les deux franchissent la frontière de la DLL, donc le wrapper .NET et tout autre hôte qui consomme sgcWebSockets.dll en bénéficient aussi. Les nouveaux exports sont ajoutés à la fin, l'ordre des exports existants reste donc inchangé.

Les moteurs EPOLL et IOCP

Les moteurs haute performance présentaient une catégorie de défauts ayant une seule cause : ils supposaient qu'une requête arrive en une seule lecture de socket. C'est vrai dans un test en boucle locale et faux à toute limite de MTU, à travers un VPN, ou dès qu'un corps volumineux est réparti sur plusieurs paquets.

Une requête qui n'arrivait pas en entier était abandonnée, la connexion fermée et sans réponse, et un enregistrement TLS réparti sur deux segments TCP fermait purement et simplement la connexion. Les deux sont corrigés, et la nouvelle option PartialRequestTimeout borne le temps que le serveur attend pour le reste, sur un pool de threads distinct pour qu'un client lent ne puisse pas bloquer les autres. Sur le moteur EPOLL, les connexions serveur n'étaient en outre jamais libérées une fois le client déconnecté, donc OnDisconnect ne se déclenchait jamais et chaque diffusion continuait d'écrire dans une connexion morte.

C'est aussi pourquoi WorkOpThreads a changé de sens. Il n'épingle plus une connexion à un thread, car une connexion en attente du reste d'une requête bloquait toutes les autres connexions de ce thread. Il fixe désormais le nombre minimal de workers tenus prêts, et le pool grandit à partir de là.

QUIC et HTTP/3

Le client et le serveur QUIC et HTTP/3 parlent maintenant IPv6. Une adresse contenant un deux-points est traitée comme de l'IPv6, une URL peut la porter entre crochets, et un nom d'hôte est résolu sur les deux familles, là où seul IPv4 était essayé auparavant. L'écouteur HTTP/3 sans hôte défini sert les deux familles à travers une seule socket, et une nouvelle propriété Host sur HTTP3Options le fixe sur une seule interface quand vous en avez besoin.

Le changement le plus important est que les requêtes HTTP/3 suivent désormais le même chemin que les requêtes HTTP/1.1. Les serveurs d'API OpenAPI, MCP et REST, le transfert de requêtes, CORS, la multi-location et les métriques ne répondaient pas du tout en HTTP/3, parce que ce transport avait son propre chemin. Tous fonctionnent maintenant.

La vérification de certificat en HTTP/3 est le point à lire deux fois. TLSOptions.VerifyCertificate valait True par défaut sur TsgcHTTP3Client, le contrôle était effectué, puis le résultat était jeté, si bien que tout client HTTP/3 acceptait n'importe quel certificat de n'importe quelle autorité émis pour n'importe quel hôte. Le contrôle est désormais appliqué, ce qui veut dire qu'un client HTTP/3 qui parle à un point de terminaison auto-signé cesse de se connecter tant que le magasin de confiance ou le certificat n'est pas corrigé.

Les clients d'API des plateformes d'échange

Les clients de plateformes d'échange prêts à l'emploi avaient un problème de reconnexion qui se manifestait comme un problème bien plus étrange. Les abonnements privés, les flux d'ordres, de soldes et d'exécutions, n'étaient jamais rejoués après une reconnexion sur Bitstamp, Coinbase, Deribit, Huobi, Kraken spot et futures, Kucoin, MEXC et ThreeCommas. Le composant signalait la reconnexion comme réussie alors que ces flux avaient silencieusement disparu. Sur BitMEX, Bitfinex, Crypto.com, Deribit et Kraken futures, le rejeu s'exécutait avant l'authentification, ce qui ne peut pas fonctionner non plus. Les trames portant un identifiant à durée de vie courte sont maintenant reconstruites avec un identifiant frais au moment du rejeu, au lieu d'être simplement réémises.

Les montants étaient arrondis avant d'être signés. Un masque fixe à huit décimales transformait une taille comme 0.000000004 en zéro, et les valeurs pouvaient partir en notation scientifique ou avec une virgule comme séparateur selon la locale du système. Les valeurs sont désormais écrites sans perte, en décimal simple, avec un point, sur Binance, Bybit, Cex, Cryptohopper, Kucoin, MEXC et ThreeCommas.

Nouveautés dans le même domaine : un composant Kraken WebSocket v2 à côté de celui en v1, un client Huobi qui ouvre une seconde connexion en interne pour qu'une seule instance serve à la fois les données publiques et privées, UseServerTimeOffset sur Binance pour une machine dont l'horloge a dérivé, et deux options de limitation, PaceBatch et AsyncResubscribe, qui empêchent un abonnement volumineux de déclencher la limite de débit de la plateforme et déplacent le rejeu de reconnexion sur un worker en arrière-plan.

sgcWebSockets .NET 2026.9.0

La bibliothèque .NET suit celle en Delphi. OnQueueDrained et PendingCount arrivent avec la même signification, accompagnés de Throttle.AsyncResubscribe, de AllowUnsignedWebhooks sur le client Cryptohopper, et d'un nouvel événement OnBinanceUserStreamSubscribed pour que la disponibilité du flux de données utilisateur n'ait plus à être découverte en interrogeant une propriété en boucle.

Toutes les corrections de reconnexion et de signature des plateformes d'échange listées plus haut s'appliquent ici aussi, tout comme les suppressions. Le protocole AppRTC, l'API RTCMultiConnection et les classes de repli Flash ont disparu, ce qui renumérote TwsTransport. Le code qui persistait ou transmettait la valeur numérique du transport doit être revu.

Deux fuites méritent d'être citées : un composant d'API WebSocket libéré alors que son client était encore connecté ne se retirait jamais de la liste parcourue par le gestionnaire de messages, et deux threads de minuterie de battement de cœur fuyaient pour chaque composant détruit, ce qui explique qu'un arrêt propre échouait de temps en temps.

sgcSign 2026.9.0

L'essentiel de cette version vient de demandes de clients, et elle porte sur trois domaines : savoir avec quel certificat vous êtes sur le point de signer, construire une signature qu'un validateur acceptera encore dans dix ans, et vérifier une signature par rapport à autre chose qu'elle-même.

Des listes de certificats dans lesquelles vous pouvez choisir

L'énumération des certificats renvoyait auparavant des noms d'affichage, ce qui suffit à remplir une liste déroulante mais pas à prendre une décision. Deux cartes de la même autorité, délivrées à la même personne, sont identiques dans cette liste. L'énumération porte désormais l'empreinte SHA-1, l'identifiant fiscal, le numéro de série, l'émetteur et les dates de validité, de la même manière pour le magasin de certificats Windows, un token PKCS#11 et un fichier PFX.

uses
  sgcSign_KeyProvider_WinCertStore, sgcSign_X509, sgcSign_Types;

var
  oProvider: TsgcWindowsCertStoreProvider;
  oList: TsgcX509CertificateList;
  i: Integer;
begin
  oProvider := TsgcWindowsCertStoreProvider.Create(nil);
  Try
    // only certificates that are still valid and hold a private key
    oList := oProvider.EnumerateCertificateList([cfNotExpired, cfPrivateKey]);
    Try
      for i := 0 to oList.Count - 1 do
        Memo1.Lines.Add(Format('%s | %s | %s .. %s | %s',
          [oList[i].Subject, oList[i].SerialNumber,
           DateToStr(oList[i].NotBefore), DateToStr(oList[i].NotAfter),
           oList[i].Thumbprint]));

      // and sign with exactly the one that was chosen
      oProvider.SelectCertificateByThumbprint(oList[0].Thumbprint);
    Finally
      oList.Free;
    End;
  Finally
    oProvider.Free;
  End;
end;

Une carte PKCS#11 à plusieurs emplacements, courante avec les cartes de signature qualifiée polonaises qui placent des certificats distincts derrière des codes PIN distincts, peut maintenant être inventoriée sans aucun PIN. EnumerateCertificateListAllSlots lit chaque emplacement, chaque entrée enregistrant sa provenance, et TokenSlotCount indique combien d'emplacements contiennent réellement un token.

Les certificats eux-mêmes exposent également tout ce qu'ils contiennent, au lieu des sept attributs que l'analyseur reconnaissait auparavant, avec l'adresse postale décodée en lignes lisibles, et n'importe quel attribut accessible par son OID.

Des signatures qui restent vérifiables

PAdES gagne deux profils. spPAdESBasicT signe avec un horodatage intégré et sans données de révocation, et spPAdESDocumentArchive ajoute un horodatage d'archive par-dessus le profil long terme, couvrant tout le document, y compris ses données de révocation, pour que le fichier reste vérifiable une fois passée la fenêtre de validité du premier horodatage.

Trouver le certificat émetteur était auparavant votre problème, car la plupart des cartes de signature qualifiée ne portent que votre propre certificat. Les nouveaux appels GetIssuerCertificate et GetCertificateChain trouvent le certificat qui a émis celui avec lequel vous signez, ainsi que tout le chemin au-dessus, en faisant correspondre cryptographiquement plutôt que par le nom, de sorte qu'une autorité ayant changé de clé de signature n'est pas confondue avec son prédécesseur. IssuerLookup décide où chercher : le magasin de certificats Windows par défaut, des fichiers PEM ou DER que vous livrez, ou l'adresse contenue dans le certificat, qui est désactivée par défaut.

Les requêtes d'horodatage peuvent désormais être signées, ce que certaines autorités qualifiées exigent, les polonaises en particulier. Réglez RequestFormat sur trfCMS, affectez un fournisseur de clés, et OnBeforeSendRequest et OnAfterReceiveResponse vous remettent les octets exacts envoyés et reçus.

La vérification avec des ancres de confiance

C'est le changement à lire attentivement. Jusqu'à présent, le vérificateur extrayait le certificat de signature du document qu'il contrôlait et confirmait que cette clé avait signé ce document, ce qui prouve seulement que celui qui a écrit le document a aussi écrit la signature qu'il contient.

Les nouvelles propriétés TrustedCertificates et TrustedCertificateStore indiquent quelles racines vous approuvez, et RequireTrustedChain, CheckKeyUsage et RequireCompleteRevocationCheck décident de la sévérité du résultat. Une ancre est reconnue par empreinte SHA-256 ou en vérifiant sous sa propre clé, jamais par le nom. Un vérificateur sans ancre renvoie le verdict qu'il renvoyait avant, mais le rapport ETSI TS 119 102-2 n'indique plus total-passed pour une signature qui n'a jamais été chaînée à une ancre, les rapports stockés produits sans ancre doivent donc être régénérés.

La signature Authenticode peut désormais intégrer des certificats supplémentaires, exactement ce que fait signtool /ac, afin qu'une signature de pilote en mode noyau puisse se chaîner jusqu'à la Microsoft Code Verification Root via son certificat croisé.

Un seul transport HTTP, avec les proxies

Toutes les requêtes que la bibliothèque effectue passent maintenant par un seul transport doté d'une propriété HTTPOptions partagée : le client d'horodatage, les clients OCSP et de listes de révocation, le téléchargement de la liste de confiance européenne et les fournisseurs de clés cloud. Il porte le proxy, qui peut être celui du système, aucun, une adresse explicite ou celui que la machine résout pour chaque adresse, les identifiants pour un proxy qui les demande, le certificat client, la version TLS minimale acceptée et l'agent utilisateur. Chaque réglage prend par défaut ce que ces requêtes faisaient auparavant, et un nouvel événement OnHTTPRequest remplace entièrement le transport pour une passerelle que ces réglages ne peuvent pas décrire.

Le serveur de signature

Les clés d'API et les utilisateurs qui les créent sont maintenant isolés par projet, de sorte qu'un administrateur de projet gère les clés de son propre projet sans voir celles des autres. Les clés peuvent être activées et désactivées au lieu d'être seulement révoquées sans retour possible, leur limite de débit et leur quota quotidien peuvent être modifiés après la création, et le journal d'audit peut enfin être filtré par adresse de client, à la fois dans la console et dans l'export CSV.

Une signature Authenticode peut désormais porter plus de deux signatures imbriquées avec un certificat différent pour chacune, ce qu'exige la livraison d'un fichier signé à la fois par un certificat qui expire et par son remplaçant. Les fichiers de catalogue Windows peuvent être signés, et un nouveau point de terminaison /api/v1/sign/raw signe une empreinte que vous avez déjà calculée et ne renvoie que la valeur de la signature, ce qui est exactement ce que signtool demande à travers son rappel /dlib. Comme il signe n'importe quelle empreinte qu'on lui remet, il est désactivé par défaut et s'active un fournisseur à la fois.

Plusieurs valeurs par défaut du serveur ont changé pour de bonnes raisons. Le réglage server.listen lie désormais réellement l'adresse que vous lui avez donnée, les actions d'administration exigent un envoi de formulaire portant un jeton à usage unique, et les livraisons de webhooks en HTTPS vérifient le certificat de l'adresse à laquelle elles sont envoyées. Les trois figurent dans les notes de mise à jour.

sgcIndy 2026.9.0

Une petite version, et chacun de ses éléments est une correction qui vaut la peine.

Le nom de protocole convenu via ALPN était écrit sur quatre octets dans l'unique octet qu'OpenSSL réserve à sa longueur, si bien que chaque poignée de main ayant négocié un protocole écrasait la mémoire voisine. Un serveur TLS sur le moteur IOCP ou EPOLL consommait tout le CPU d'un thread quand l'autre extrémité demandait une renégociation, en réessayant l'écriture encore et encore au lieu d'envoyer ce qu'OpenSSL avait déjà préparé. Sous Linux, une application TLS était fermée par le système d'exploitation quand l'autre extrémité réinitialisait la connexion pendant une écriture, parce qu'OpenSSL écrit d'une manière qui ne permet pas de demander au système de supprimer le signal de tube rompu. Le même problème sous FPC et Lazarus est corrigé lui aussi, y compris pour les connexions acceptées côté serveur sur macOS, qui restaient exposées.

Pour l'installation Community, les binaires Delphi 13 précompilés étaient produits à partir des projets Delphi 12, ils portaient donc les noms en 290 au lieu des noms en 370 attendus par l'installeur Delphi 13, et Windows ARM64EC n'était pas construit du tout. Delphi 13 construit désormais ses propres projets pour toutes les plateformes prises en charge.

sgcOpenAPI 2026.9.0

L'analyseur a cessé d'échouer en silence. Chaque document revient désormais avec une liste Warnings contenant un membre openapi ou info manquant, un membre au mauvais type JSON, une opération qui n'a pas pu être générée, une référence d'élément de chemin non résolue et tout mot-clé JSON Schema qui est lu mais pas encore honoré.

uses
  sgcOpenAPI_Classes, sgcOpenAPI_Parser_Client_Pascal;

var
  oParser: TsgcOpenAPI_Parser_Client_Pascal;
  i: Integer;
begin
  oParser := TsgcOpenAPI_Parser_Client_Pascal.Create;
  Try
    oParser.OpenAPIClassName := 'TPetStoreClient';
    oParser.OutputFileName := 'PetStoreClient.pas';

    oParser.ReadFromFile('petstore.json');

    for i := 0 to oParser.Warnings.Count - 1 do
      Memo1.Lines.Add('warning: ' + oParser.Warnings[i]);

    oParser.SaveToFile('PetStoreClient.pas');
  Finally
    oParser.Free;
  End;
end;

Il sait aussi quelle version de la spécification il est en train de lire, si bien qu'un document 3.0 et un document 3.1 ne sont plus traités de la même façon, exclusiveMinimum et exclusiveMaximum en étant le cas évident. Les webhooks OpenAPI 3.1, jsonSchemaDialect, components.pathItems, l'identifiant de licence, le schéma de sécurité mutualTLS, un type déclaré sous forme de tableau comme ["string","null"] et un schéma déclaré comme booléen sont tous pris en charge, ainsi que l'opération query d'OpenAPI 3.2 et la table additionalOperations.

La génération s'est améliorée là où elle renonçait auparavant. Un schéma d'objet en ligne génère maintenant sa propre classe au lieu de se dégrader en chaîne, items est lu comme un schéma complet, et le client généré prend en charge les paramètres de cookie et l'ensemble des règles de sérialisation des paramètres : matrix, label, simple, form, spaceDelimited, pipeDelimited et deepObject, avec explode et allowReserved.

La ligne de commande est enfin utilisable dans un script de build. Elle définit un code de sortie, 0 en cas de succès et 1 à 7 pour les différents échecs, et les erreurs vont toujours sur la sortie d'erreur standard. Un nouveau commutateur -r convertit un document YAML ou Swagger 2.0 à travers le convertisseur public, désactivé par défaut.

Les mêmes améliorations OpenAPI sont livrées dans sgcWebSockets, où le validateur côté serveur contrôle maintenant aussi les paramètres d'en-tête et de cookie, avec ValidateHeaderParams, ValidateCookieParams et EnforceRequired.

Avant de mettre à jour

Chaque produit comporte cette fois des changements incompatibles. Voici ceux qui ont le plus de chances de vous concerner.

La liste complète, avec la raison de chacun, se trouve dans le changelog de chaque produit.

Comment l'obtenir

La version 2026.9.0 est disponible dès maintenant, avec le code source complet et un an de mises à jour, pour Delphi 7 jusqu'à Delphi 13 Florence, les versions de C++ Builder correspondantes, et .NET.

sgcWebSockets · sgcWebRTC · sgcCrypto · sgcHTML · sgcSign · sgcIndy · sgcOpenAPI

Télécharger la version d'essai · Changelog

Des questions ou des remarques ? Contactez-nous, vous recevrez une réponse des personnes qui ont écrit le code.