Modifiez un proxy inverse Rust sans casser la boucle d’événements ni la sécurité

## Respectez les couches de bibliothèques du proxy et le sens des dépendances Traitez le dépôt comme un système en couches dont le sens des dépendances est explicite : - Une bibliothèque de plan de contrôle gère l’analyse de la configuration, les schémas de commandes, l’état partagé, les utilitaires de journalisation et les canaux interprocessus. - Une bibliothèque de protocole et d’exécution gère la boucle d’événements monothread, le routage, les sockets, les tampons, les métriques, TLS, HTTP et le protocole de proxy. - Un crate binaire gère le superviseur, les processus de travail, la CLI, le chargement de la configuration, la reconfiguration à chaud, les mises à niveau et le serveur de commandes. - Les crates de tests d’intégration et de simulation déterministe dépendent des bibliothèques d’exécution, mais ne doivent pas laisser leurs dépendances asynchrones ou réservées aux tests contaminer le code de production. - Les cibles de fuzzing peuvent résider hors de l’espace de travail principal lorsque leurs chaînes d’outils ont des exigences différentes. Préservez le sens des dépendances du code d’exécution vers celui du plan de contrôle. Maintenez chaque processus de travail sur un seul thread, évitez les mutex partagés dans la boucle d’événements et gardez les bibliothèques de production exemptes d’environnements d’exécution asynchrones, sauf refonte délibérée de l’architecture. ## Compilez avec la toolchain fixée et testez les combinaisons de fonctionnalités Avant de modifier le code, identifiez la chaîne d’outils Rust épinglée et les générateurs de code requis. Si la génération de schémas est un prérequis impératif, installez ou vérifiez le générateur avant d’interpréter les échecs de compilation. Utilisez des dépendances verrouillées pour les constructions et tests ordinaires. Exécutez l’outil de formatage avec la chaîne d’outils exigée par la configuration du dépôt, l’analyse statique en refusant les avertissements, puis les tests de tout l’espace de travail avant les travaux de publication. Utilisez des suites ciblées pendant l’itération, puis revenez aux contrôles de l’espace de travail concerné. Traitez les indicateurs de fonctionnalités comme des cellules de compatibilité explicites : - Documentez les choix par défaut de l’allocateur et de la cryptographie. - Testez séparément chaque fournisseur de cryptographie pris en charge, y compris les modes axés sur la conformité. - N’activez jamais les points d’injection de tests dans les constructions de production. - Gardez facultatives la journalisation de débogage ou de suivi, la tolérance de l’analyseur, SIMD, les E/S sans copie et la télémétrie lorsqu’elles modifient le comportement, l’empreinte ou l’observabilité. Ne déclarez pas une modification saine au seul motif qu’une construction par défaut a réussi. Vérifiez les combinaisons de fonctionnalités directement touchées. ## Gérez erreurs et journaux sans panic et ne modifiez pas le code généré à la main Utilisez des erreurs de bibliothèque structurées et n’ajoutez un contexte étendu qu’aux frontières des exécutables. Une entrée contrôlée par le réseau doit devenir une erreur de protocole, une action de connexion, une métrique et un journal contextualisé ; elle ne doit jamais déclencher `unwrap`, `expect`, `panic` ni une branche inaccessible sur le chemin de publication. Suivez les conventions de propriété du code voisin. Préférez des conversions révélant l’intention lorsque vous transformez des chaînes ou octets empruntés en valeurs possédées, et utilisez un clonage ordinaire lorsque le type est déjà une valeur possédée et clonable. Les modules de protocole doivent utiliser leurs macros établies de journalisation contextuelle et des balises de recherche stables. Préservez l’enveloppe canonique session/requête/backend afin que les opérateurs puissent corréler les échecs. Utilisez le débogage ou le suivi pour les fermetures d’inactivité attendues et les états bruyants ; réservez les niveaux d’avertissement et d’erreur aux véritables fautes de protocole ou ruptures d’invariants. Conservez les métriques publiques dans la couche centrale des métriques et actualisez la référence de configuration destinée aux utilisateurs lorsque vous en ajoutez ou renommez une. Traitez le sous-dépassement d’une jauge comme un défaut d’exactitude. Ne modifiez jamais manuellement les liaisons de protocole générées. Modifiez le schéma source et régénérez-les par la construction. Tout nouveau code non sûr dans un chemin critique exige une explication proche de l’invariant et un test ciblé. ## Empêchez les écritures socket et les tampons de bloquer la boucle d’événements Pour des E/S déclenchées par front, mettre en file des octets depuis un chemin de lecture ne suffit pas : signalez explicitement qu’une écriture est en attente. Sans ce signal, des sessions se bloquent uniquement à certaines limites de trame ou de tampon. Gardez structurellement symétriques les implémentations scalaires et vectorisées d’écriture sur socket, y compris les nouvelles tentatives et écritures partielles. Sur les interfaces chiffrées, évitez un arrêt duplex complet susceptible d’émettre une réinitialisation et de tronquer des octets déjà en file ; fermez le côté écriture et laissez la fermeture du pair suivre le chemin de lecture normal. Maintenez un tampon assez grand pour la trame de protocole maximale et son en-tête. Validez cette configuration au démarrage plutôt que de laisser un petit tampon bloquer le code de découpage en trames. Séparez l’état de connexion au niveau du fil de l’état du flux propriétaire du tampon, et reliez-les par des identifiants stables assortis de règles de cycle de vie vérifiées. La négociation du protocole côté client et les indications de capacité côté backend sont deux notions distinctes ; n’utilisez pas accidentellement l’une comme contrôle de l’autre. Les protections contre les inondations doivent couvrir les tempêtes de réinitialisations, les chaînes de continuation, les trames de contrôle répétées et l’abus de priorité. La reconfiguration à chaud multiprocessus doit valider les commandes dans le superviseur avant de les distribuer aux processus de travail monothread. ## Testez par couches avec du fuzzing et des simulations rejouables Utilisez cinq couches de tests complémentaires : tests unitaires près des modules, tests d’intégration au niveau des processus, cibles de fuzzing, simulation déterministe pour les machines à états sans E/S et protections contre les régressions de contrats structurels tels que la disposition des journaux. Pour les analyseurs et fonctions non triviales de machines à états, encodez les préconditions, les postconditions et des assertions positives et négatives dans les constructions de débogage. Les points d’entrée publics des machines à états doivent se terminer par un contrôle complet des invariants. Les assertions décrivent des impossibilités internes ; une entrée réseau hostile doit néanmoins produire un résultat de protocole sûr. Pilotez les simulations déterministes avec une source aléatoire initialisée par une graine, un temps virtuel, des charges hostiles et l’injection de fautes. Consignez les graines pour pouvoir reproduire chaque échec. Limitez au crate de simulation les indicateurs d’exécution et dépendances réservés à la simulation. Les tests d’intégration doivent allouer les ports dynamiquement, lire des réponses TCP complètes plutôt qu’un seul segment et utiliser des échéances explicites ou des conditions de nouvelle tentative jusqu’à réussite plutôt que des attentes arbitraires. Un test ignoré exige une dépendance concrète à l’environnement ou un motif suivi ; n’utilisez jamais l’ignorance pour masquer une régression. Pour les modifications de mise à niveau, d’analyse, de compression ou de découpage en trames, exécutez la suite d’intégration dédiée et les cibles de fuzzing correspondantes en plus des tests généraux. ## Modifiez TLS, parseurs et framing avec prudence et des tests de régression Apportez des modifications prudentes et étayées par des tests à la configuration TLS, la négociation du protocole, la liaison des noms, le chargement des certificats, la normalisation de l’analyseur et des en-têtes, le contrôle de flux, le découpage des commandes, le transfert de descripteurs, les métriques et les journaux. Rejetez un découpage ambigu des messages plutôt que de transmettre une représentation différente du découpage réellement appliqué. Préservez l’ordre des pseudo-en-têtes, la conciliation de la longueur du contenu, les défenses contre la contrebande de requêtes et la sémantique correcte de réinitialisation ou de fermeture progressive. Pour les canaux de commandes, validez les préfixes de longueur, les messages partiels, le transfert de descripteurs de fichiers, la relecture de l’état et les limites des tampons. Pour le protocole de proxy, couvrez les en-têtes partiels et surdimensionnés ainsi que le trafic de contrôle d’intégrité. N’exposez aucun secret ni aucune valeur sensible dans les journaux ou métriques. Maintenez l’exactitude des compteurs et jauges sur tous les chemins d’erreur et d’arrêt. Lors d’une modification de la boucle d’événements ou du code de sécurité, ajoutez une couverture de régression ciblée sur l’invariant exact, puis exécutez les tests de protocole voisins. Ne mêlez aucune refactorisation sans rapport à la même modification. ## Indiquez dans les pull requests l’impact sur le protocole et la sécurité Lisez la note canonique sur le cycle de vie ou l’architecture avant de modifier un sous-système de protocole complexe. Considérez les anciens documents comme des indices et confrontez leurs références de fichiers au code actuel. Utilisez des branches ciblées et des messages de commit conventionnels identifiant le sous-système concerné. Respectez la politique de signature et d’approbation du dépôt. Lorsqu’une tâche autorise la publication, poussez la branche validée et signalez l’exécution CI obtenue ; sinon, arrêtez-vous à la limite autorisée localement. Fondez les modifications sur la branche par défaut actuelle, sauf si une branche d’intégration active est explicitement nommée. Les demandes d’intégration doivent décrire l’impact sur le protocole ou la sécurité, les commandes exécutées, les tests ajoutés et les changements de documentation. Respectez les contrôles de propriété et de licence des contributeurs. Actualisez les journaux des modifications et les références de configuration lorsqu’un comportement visible par les utilisateurs ou les opérateurs change, notamment les clés de configuration, les métriques, les indicateurs de ligne de commande et les exigences de mise à niveau. Avant le transfert, examinez le diff pour repérer les fichiers générés, les fuites accidentelles de fonctionnalités, les tests manquants, les références obsolètes et les modifications sans rapport. ## Publiez seulement avec accord et testez d’abord les mises à jour à chaud Traitez le déploiement comme une étape autorisée séparément. Commencez par construire l’artefact de publication avec des dépendances verrouillées ou figées, puis validez la configuration et exécutez les contrôles de préparation concernés dans un environnement équivalent à la préproduction. Les paquets de conteneur et de système d’exploitation doivent installer les mêmes prérequis de construction que ceux utilisés localement, y compris les générateurs de schémas et les bibliothèques de plateforme. Épinglez la chaîne d’outils et excluez les dépendances réservées aux tests des artefacts de production. Pour les régressions de boucle d’événements ou de cycle de vie des processus de travail, reproduisez avec un seul processus de travail, le redémarrage automatique désactivé et les traces d’appels activées. Cela maintient le premier échec visible au lieu de laisser la récupération du superviseur le masquer. Les mises à niveau à chaud doivent préserver les invariants de transfert des écouteurs et des sessions. Testez explicitement les chemins de mise à niveau avant la publication. Ne considérez pas un redémarrage ordinaire réussi comme une preuve que le transfert ou la relecture des descripteurs fonctionne. Ne déployez pas en production, ne modifiez pas les identifiants d’accès et n’effectuez pas de récupération destructive sans autorisation explicite et sans chemin de retour arrière. Indiquez ce qui a été construit, les contrôles réussis, ce qui reste non vérifié et la limite exacte à laquelle le travail s’est arrêté.