Ändere einen Rust-Reverse-Proxy, ohne Ereignisschleife und Sicherheit zu beschädigen

## Halte die Bibliotheksschichten und die Abhängigkeitsrichtung des Proxys ein Behandle das Repository als Schichtsystem mit ausdrücklich festgelegter Abhängigkeitsrichtung: - Eine Bibliothek der Steuerungsebene ist für das Einlesen der Konfiguration, Befehlsschemata, gemeinsamen Zustand, Protokollierungshilfen und Kanäle zwischen Prozessen zuständig. - Eine Protokoll- und Laufzeitbibliothek ist für die in einem einzelnen Thread ausgeführte Ereignisschleife, Weiterleitung, Sockets, Puffer, Messgrößen, TLS, HTTP und die Verarbeitung des Proxy-Protokolls zuständig. - Ein Binär-Crate ist für den Überwachungsprozess, die Arbeitsprozesse, die Kommandozeilenschnittstelle, das Laden der Konfiguration, die laufende Neukonfiguration, Aktualisierungen und den Befehlsserver zuständig. - Crates für Integrationstests und deterministische Simulation hängen von Laufzeitbibliotheken ab, dürfen ihre asynchronen oder ausschließlich für Tests bestimmten Abhängigkeiten jedoch nicht in den Produktionscode einbringen. - Ziele für Fuzz-Tests dürfen außerhalb des Hauptarbeitsbereichs liegen, wenn ihre Anforderungen an die Werkzeugkette abweichen. Bewahre die Abhängigkeitsrichtung vom Laufzeitcode zum Code der Steuerungsebene. Halte jeden Arbeitsprozess auf einen Thread beschränkt, vermeide gemeinsam genutzte Mutexe in der Ereignisschleife und halte Produktionsbibliotheken frei von asynchronen Laufzeitumgebungen, sofern die Architektur nicht bewusst neu gestaltet wird. ## Baue mit der festgelegten Toolchain und teste die Feature-Kombinationen Ermittle vor Codeänderungen die festgelegte Rust-Werkzeugkette und die erforderlichen Codegeneratoren. Ist die Schemaerzeugung eine zwingende Voraussetzung, installiere oder überprüfe den Generator, bevor du Kompilierungsfehler deutest. Verwende für normale Erstellungen und Tests festgeschriebene Abhängigkeiten. Führe das Formatierungswerkzeug mit der von der Repository-Konfiguration verlangten Werkzeugkette aus, führe die statische Prüfung so aus, dass Warnungen abgewiesen werden, und teste vor veröffentlichungsbezogenen Arbeiten den gesamten Arbeitsbereich. Verwende während der Entwicklung gezielte Testsammlungen und kehre anschließend zu den Prüfungen auf Ebene des betroffenen Arbeitsbereichs zurück. Behandle Funktionsschalter als klar abgegrenzte Kompatibilitätsvarianten: - Dokumentiere die standardmäßige Wahl des Speicherzuweisers und der Kryptografie. - Teste jeden unterstützten Kryptografieanbieter getrennt, einschließlich auf die Einhaltung von Vorgaben ausgerichteter Betriebsarten. - Aktiviere Schnittstellen zur Testeinschleusung niemals in Produktionserstellungen. - Halte Fehlersuch- oder Ablaufprotokollierung, fehlertolerantes Einlesen, SIMD, kopierfreie Ein-/Ausgabe und Telemetriefunktionen ausdrücklich zuschaltbar, wenn sie Verhalten, Größe oder Beobachtbarkeit verändern. Bezeichne eine Änderung nicht als fehlerfrei, nur weil eine einzige Standarderstellung erfolgreich war. Prüfe die von der Änderung unmittelbar betroffenen Funktionskombinationen. ## Behandle Fehler und Logs ohne Panic und bearbeite erzeugten Code nicht von Hand Verwende strukturierte Bibliotheksfehler und füge umfassenden Kontext nur an den Grenzen ausführbarer Programme hinzu. Netzwerkgesteuerte Eingaben müssen zu einem Protokollfehler, einer Verbindungsaktion, einer Messgröße und einem kontextbezogenen Protokolleintrag führen; sie dürfen im Auslieferungspfad niemals `unwrap`, `expect`, `panic` oder einen als unerreichbar markierten Zweig auslösen. Halte dich an die Besitzkonventionen des benachbarten Codes. Bevorzuge Umwandlungen, die die Absicht erkennen lassen, wenn geliehene Zeichenketten oder Bytes in Werte mit eigenem Besitz überführt werden, und verwende gewöhnliches Klonen, wenn der Typ bereits ein klonbarer Wert mit eigenem Besitz ist. Protokollmodule müssen ihre etablierten Makros für kontextbezogene Protokollierung und beständigen Suchkennzeichnungen verwenden. Bewahre den kanonischen Sitzungs-, Anfrage- und Zielserverkontext, damit Betriebspersonal Fehler zusammenführen kann. Verwende Fehlersuch- oder Ablaufebenen für erwartete Leerlaufschließungen und häufige Zustandsmeldungen; Warn- und Fehlerebenen bleiben echten Protokollfehlern oder Invariantenverletzungen vorbehalten. Halte öffentliche Messgrößen in der zentralen Messgrößenschicht und aktualisiere die benutzerbezogene Konfigurationsreferenz, wenn du eine Messgröße hinzufügst oder umbenennst. Behandle den Unterlauf eines Zustandsmessers als Korrektheitsfehler. Bearbeite erzeugte Protokollanbindungen niemals von Hand. Ändere das Quellschema und erzeuge sie über den Erstellungsvorgang neu. Neuer `unsafe`-Code in einem leistungskritischen Pfad erfordert eine nahe stehende Erklärung der Invariante und einen gezielten Test. ## Verhindere, dass Socket-Schreibvorgänge und Puffer die Ereignisschleife blockieren Bei flankengetriggerter Ein-/Ausgabe reicht es nicht aus, Bytes aus einem Lesepfad in die Warteschlange zu stellen: Melde ausdrücklich die ausstehende Schreibbereitschaft. Fehlt dieses Signal, entstehen Sitzungen, die nur an bestimmten Rahmen- oder Puffergrenzen zum Stillstand kommen. Halte skalare und vektorisierte Schreibimplementierungen für Sockets strukturell symmetrisch, einschließlich des Verhaltens bei Wiederholungsversuchen und teilweisem Schreiben. Vermeide bei verschlüsselten Eingangsseiten ein vollständiges bidirektionales Herunterfahren, das eine Rücksetzung auslösen und bereits eingereihte Bytes abschneiden kann; schließe die Schreibseite und lasse das Schließen durch die Gegenstelle dem normalen Lesepfad folgen. Halte einen Puffer vor, der groß genug für den maximalen Protokollrahmen zuzüglich seines Kopfes ist. Prüfe diese Konfiguration beim Start, statt zuzulassen, dass ein zu kleiner Puffer den Rahmencode blockiert. Trenne den Verbindungszustand auf Leitungsebene vom pufferbesitzenden Datenstromzustand und verknüpfe beide über beständige Kennungen mit geprüften Lebenszyklusregeln. Die Protokollaushandlung auf der Eingangsseite und Fähigkeitshinweise der Zielserverseite sind verschiedene Konzepte; verwende keines davon versehentlich als Schranke für das andere. Überlastungsschutz muss Rücksetzungsstürme, Fortsetzungsketten, wiederholte Steuerrahmen und Prioritätsmissbrauch abdecken. Bei laufender Neukonfiguration über mehrere Prozesse muss der Überwachungsprozess Befehle prüfen, bevor er sie an die jeweils einthreadigen Arbeitsprozesse verteilt. ## Teste in Schichten mit Fuzzing und wiederholbaren Simulationen Verwende fünf einander ergänzende Testschichten: Modultests neben den Modulen, Integrationstests auf Prozessebene, Ziele für Fuzz-Tests, deterministische Simulation für ein-/ausgabeunabhängige Zustandsautomaten und Regressionswächter für strukturelle Verträge wie den Aufbau von Protokolleinträgen. Lege für Einleser und nicht triviale Zustandsautomatenfunktionen Vorbedingungen, Nachbedingungen sowie positive und negative Zusicherungen in Fehlersucherstellungen fest. Öffentliche Einstiegspunkte von Zustandsautomaten sollten mit einer vollständigen Invariantenprüfung enden. Zusicherungen beschreiben intern unmögliche Zustände; feindliche Netzwerkeingaben müssen dennoch ein sicheres Protokollergebnis zurückgeben. Steuere deterministische Simulationen mit einer gesetzten Zufallsquelle, virtueller Zeit, feindlichen Arbeitslasten und Fehlereinschleusung. Zeichne die Startwerte auf, damit jeder Fehler wiederholt werden kann. Beschränke ausschließlich für Simulationen bestimmte Laufzeitschalter und Abhängigkeiten auf den Simulations-Crate. Integrationstests müssen Ports dynamisch zuweisen, vollständige TCP-Antworten statt nur eines Segments lesen und ausdrückliche Fristen oder Wiederholungen bis zum Eintritt einer Bedingung statt willkürlicher Pausen verwenden. Ein ignorierter Test benötigt eine konkrete Umgebungsabhängigkeit oder einen nachverfolgten Grund; verwende das Ignorieren niemals, um eine Regression zu verbergen. Führe bei Änderungen an Aktualisierung, Einlesen, Komprimierung oder Rahmenbildung zusätzlich zu den allgemeinen Tests die zugehörige Integrationstestsammlung und die passenden Ziele für Fuzz-Tests aus. ## Ändere TLS, Parser und Framing vorsichtig und mit Regressionstests Nimm konservative, durch Tests abgesicherte Änderungen an der TLS-Einrichtung, Protokollaushandlung, Namensbindung, Zertifikatsladung, Einleser- und Kopfzeilennormalisierung, Flusssteuerung, Befehlsrahmung, Deskriptorweitergabe, Messgrößen und Protokollen vor. Weise mehrdeutige Nachrichtenrahmung zurück, statt eine Darstellung weiterzuleiten, die von der tatsächlich angewandten Rahmung abweicht. Bewahre die Reihenfolge der Pseudokopfzeilen, den Abgleich der Inhaltslänge, Schutzmaßnahmen gegen das Einschmuggeln von Anfragen und die richtige Semantik für Rücksetzung oder geordnetes Schließen. Prüfe bei Befehlskanälen Längenpräfixe, Teilnachrichten, die Übertragung von Dateideskriptoren, Zustandswiedergabe und Puffergrenzen. Decke bei der Verarbeitung des Proxy-Protokolls sowohl unvollständige und übergroße Kopfzeilen als auch Datenverkehr für Zustandsprüfungen ab. Gib keine Geheimnisse oder vertraulichen Werte über Protokolle oder Messgrößen preis. Halte Zähler und Zustandsmesser auf jedem Fehler- und Abschaltpfad korrekt. Füge bei Änderungen an der Ereignisschleife oder am Sicherheitscode gezielten Regressionsschutz für genau die betroffene Invariante hinzu und führe anschließend die benachbarten Protokolltests aus. Vermische keine sachfremde Umstrukturierung mit derselben Änderung. ## Beschreibe in Pull-Requests die Auswirkungen auf Protokoll und Sicherheit Lies vor Änderungen an einem komplexen Protokollteilsystem die maßgebliche Lebenszyklus- oder Architekturnotiz. Behandle ältere Dokumente als Hinweise und gleiche ihre Dateiverweise mit dem aktuellen Code ab. Verwende eng begrenzte Zweige und herkömmliche Commit-Nachrichten, die das betroffene Teilsystem benennen. Halte dich an die Signatur- und Bestätigungsrichtlinie des Repositorys. Wenn eine Aufgabe das Veröffentlichen erlaubt, übertrage den Zweig mit seinen Commits und berichte über den daraus entstandenen CI-Lauf; andernfalls halte an der lokal genehmigten Grenze an. Stütze Änderungen auf den aktuellen Standardzweig, sofern nicht ausdrücklich ein aktiver Integrationszweig genannt ist. Zusammenführungsanträge sollten die Auswirkungen auf Protokoll oder Sicherheit, ausgeführte Befehle, hinzugefügte Tests und Dokumentationsänderungen beschreiben. Beachte Zuständigkeits- und Mitwirkendenlizenzprüfungen. Aktualisiere Änderungsprotokolle und Konfigurationsreferenzen, wenn sich für Benutzer oder Betriebspersonal sichtbares Verhalten ändert, einschließlich Konfigurationsschlüsseln, Messgrößen, Kommandozeilenschaltern und Aktualisierungsanforderungen. Prüfe vor der Übergabe den Unterschied auf erzeugte Dateien, unbeabsichtigt eingebrachte Funktionen, fehlende Tests, veraltete Verweise und sachfremde Änderungen. ## Veröffentliche nur mit Freigabe und teste Hot-Upgrades vorher Behandle die Bereitstellung als getrennten, eigens genehmigten Schritt. Erstelle zuerst das Veröffentlichungsartefakt mit festgeschriebenen oder eingefrorenen Abhängigkeiten, prüfe dann die Konfiguration und führe die betroffenen Bereitschaftsprüfungen in einer der Vorproduktionsumgebung gleichwertigen Umgebung aus. Container- und Betriebssystempakete müssen dieselben lokal verwendeten Erstellungsvoraussetzungen installieren, einschließlich Schemageneratoren und Plattformbibliotheken. Schreibe die Werkzeugkette fest und halte ausschließlich für Tests bestimmte Abhängigkeiten aus Produktionsartefakten heraus. Stelle Regressionen der Ereignisschleife oder des Lebenszyklus von Arbeitsprozessen mit einem Arbeitsprozess, abgeschaltetem automatischem Neustart und aktivierten Aufrufstapelprotokollen nach. So bleibt der erste Fehler sichtbar, statt durch die Wiederherstellung des Überwachungsprozesses verdeckt zu werden. Laufende Aktualisierungen müssen die Invarianten der Übergabe von Empfangsstellen und Sitzungen bewahren. Teste Aktualisierungspfade vor der Veröffentlichung ausdrücklich. Betrachte einen erfolgreichen gewöhnlichen Neustart nicht als Beweis dafür, dass die Deskriptorübertragung oder Zustandswiedergabe funktioniert. Stelle nicht in der Produktionsumgebung bereit, ändere keine Zugangsdaten und führe keine zerstörerische Wiederherstellung ohne ausdrückliche Genehmigung und Rücksetzpfad durch. Berichte, was erstellt wurde, welche Prüfungen bestanden wurden, was ungeprüft bleibt und an welcher genauen Grenze die Arbeit beendet wurde.