Easton97-Jens · Easton97-Jens · May 3, 2026
diff --git a/REPORT_DE.md b/REPORT_DE.md
@@ -0,0 +1,92 @@
+# Analysebericht: ModSecurity-nginx PR #334 / #344 und verwandte Threads
+
+## Kurzfazit
+PR #334 wurde am 10. Januar 2025 gemerged, um Response-Body-Verarbeitung zu reparieren (basierend auf #326) und gleichzeitig Kontext-Verlust bei `error_page`/internal redirect zu adressieren. Am 17. Februar 2025 wurde #334 durch PR #344 vollständig revertiert. Der Revert verweist explizit auf den Verlauf in Issue #336 (Kommentar vom 24. Januar 2025), in dem der Maintainer als pragmatischen Weg das Rückgängigmachen von #334 und #326 ankündigt, mehr CI-Tests fordert und danach einen erneuten, besser abgesicherten Fix plant.
+
+Aus den untersuchten Quellen ist belegbar: Es handelt sich nicht um ein isoliertes Einzelfehlerbild, sondern um ein Zusammenspiel aus Response-Body-Handling, internen Redirects (`error_page`), Kontext-Wiederherstellung und Nginx-Phasen-Hooks. Spätere PRs (#346, #361) behandeln angrenzende, aber unterschiedliche Aspekte; #346 reintroduziert den #273-Ansatz zur Kontext-Recovery, #361 verschiebt die Hook-Phase auf `NGX_HTTP_ACCESS_PHASE` (DoS-/Performance-Begründung).
+
+## Timeline der Ereignisse
+- **2024-11-21**: In PR #326 wird kommentiert, dass es bei custom error pages/internal redirects zu neuer Transaktion und leeren `messages` in Audit-Logs kommt (in #334-Text referenziert).
+- **2025-01-10**: PR #334 („fix: response body (based on #326)“) wird gemerged.
+- **2025-01-16**: Issue #336 („Compiling Ok ... but not working“) wird im Kontext von #326 referenziert.
+- **2025-01-24**: Kommentar in #336 (issuecomment-2612803647): Maintainer nennt als möglichen Weg den Revert von #334/#326, Ausbau von CI-Tests, späteres Re-Add.
+- **2025-02-17**: PR #344 („Revert ... #334“) wird gemerged und verweist genau auf diesen Kommentar.
+- **2025-03-21**: PR #346 („re-add #273“) wird gemerged; Fokus auf Kontext-Recovery bei internal redirects.
+- **2025-12-10**: PR #361 wird gemerged; verlegt Hooking auf `NGX_HTTP_ACCESS_PHASE`.
+
+## Beteiligte Issues/PRs/Commits
+- PR #334: Merged, Commits `62639fa...`, `ae30826...`.
+- PR #344: Merged, Revert-Commit `67c9a6b...` (revertiert #334).
+- PR #326: Merged, Commit `62639fa...`.
+- PR #273: Nicht gemerged; Commits `2db3f6d...`, `5b6b4d8...`.
+- PR #346: Merged, Commit `8ed97d6...` (laut Beschreibung „copy“ von #273 + Tests).
+- PR #361: Merged, Commit `c752756...`.
+- Issue #336 Kommentar: issuecomment-2612803647.
+- ModSecurity-Repo Issue #3336: „modsecurity 3.0 interferes with nginx even when disabled.“ (geschlossen am 2025-02-18; von #344 referenziert).
+
+## Technisches Problem
+Die Quellen beschreiben mehrere gekoppelte Probleme:
+1. **Internal redirects / custom error pages** können den Nginx-Request-Kontext ändern bzw. resetten.
+2. Dadurch kann die ModSecurity-Transaktion wie „neu gestartet“ wirken (oder unvollständig sein), inkl. doppelter/inkonsistenter Phasenbehandlung.
+3. Im Umfeld von #326/#334 wurde insbesondere Response-Body-Verarbeitung und Interventionspfad verändert.
+4. Betroffen erwähnt: Regeln/Phasen rund um `REQUEST_URI` (phase:1 via URI-Verarbeitung), `REQUEST_HEADERS` (phase:1), `ARGS` (phase:2), plus Statusfälle 301/302/401/403.
+
+## Was PR #334 geändert hat
+Belegbar aus PR-Beschreibung und Diff-Dateiliste:
+- Übernahme auf Basis #326 plus zusätzliche Änderungen wegen Problemen mit custom error pages/internal redirect.
+- Breiter Austausch von `ngx_http_get_module_ctx(...)` durch `ngx_http_modsecurity_get_module_ctx(...)` inkl. Fallback über Cleanup-Handler, um Kontext bei Reset wiederzufinden.
+- Erweiterungen im Context-Struct (u.a. Flags/Felder wie `response_body_filtered`, `request_body_processed`, temporäre Chain-Pointer).
+- Geändertes Response-Body-Filter-Verhalten (Puffer-Handling/Weitergabe, `NGX_AGAIN`, verzögerte Header-Weitergabe, Intervention-Handling).
+- Anpassungen in Tests (`tests/modsecurity*.t`), darunter veränderte erwartete Antworten für Redirect/Block-Fälle.
+
+## Was PR #344 reverted hat
+PR #344 ist ein expliziter Revert von #334 („Reverts #334“). Damit wurden sämtliche #334-Änderungen zurückgenommen (Codepfad-/Kontext-Retrieval-/Body-Filter-/Teständerungen aus #334).
+
+## Warum der Revert gemacht wurde
+Explizite, belegte Begründung:
+- #344 verweist auf „history“ in Issue #336-Kommentar 2612803647.
+- In diesem Kommentar beschreibt der Maintainer, die Root Cause noch nicht gefunden zu haben und als kurzfristigen Weg #334/#326 zu revertieren, CI-Tests auszubauen und danach sauber neu anzugehen.
+
+Nicht belegbar aus den untersuchten Quellen ist eine einzelne, formal dokumentierte „finale Root Cause“-Analyse genau zum Zeitpunkt des Reverts; stattdessen wird der Revert selbst als Stabilisierungsschritt dargestellt.
+
+## Zusammenhang mit Issue #336 und dem konkreten Kommentar
+Der genannte Kommentar ist die zentrale Brücke zwischen Problembericht und Revert-Entscheidung:
+- Er nennt direkt den Plan „revert last two PR's (#334, #326)“.
+- Er fordert zusätzliche CI-Tests gegen ähnliche Regressionen.
+- Er erwähnt explizit den Versuch, #334 später wieder hinzuzufügen sowie parallel einen funktionierenden Fix für #41 zu finden.
+
+PR #344 referenziert genau diesen Kommentar; damit ist die Kausalbeziehung dokumentiert.
+
+## Zusammenhang mit #326, #273, #346 und #361
+- **#326**: Ausgangsbasis für Response-Body-Fix; #334 baut darauf auf und erweitert ihn.
+- **#273**: Früher Ansatz zur Kontext-Recovery bei internal redirect; nicht gemerged, aber inhaltlich später wieder relevant.
+- **#346**: Reintroduziert #273 (laut PR-Text „copy of #273“) plus zusätzliche Tests; wirkt wie gezieltere Nachfolge zur Redirect-Kontext-Thematik nach dem #334-Revert.
+- **#361**: Anderer Schwerpunkt (Hook-Phase PREACCESS/REWRITE → ACCESS) wegen Performance-/DoS-Verhalten; thematisch verwandt mit Request-Processing-Reihenfolge, aber nicht identisch mit dem #334-Response-Body-Revert.
+
+## Einschätzung: Bugfix, Regression, Workaround oder Architekturproblem?
+Quellenbasiert:
+- **#334**: als Bugfix intendiert.
+- **#344**: klarer Revert/Workaround zur Stabilisierung.
+- Gesamtbild: **architekturnahes Integrationsproblem** (Phasen, interner Redirect, Kontext-Lifecycle, Body-/Header-Filter-Interaktion), nicht nur ein triviales Einzelbug.
+
+## Risiken für Nutzer
+Aus den Quellen ableitbar:
+- Inkonsistente Erkennung/Logging bei internal redirects/custom error pages.
+- Potenziell falsches oder unerwartetes Verhalten bei Interventions-/Statuscodes (301/302/401/403) je nach Phase.
+- Mögliche Nebenwirkungen auf Request-/Response-Body-Verarbeitung und Header-Flow.
+- Performance-/Resilienz-Risiken bei ungünstiger Hook-Reihenfolge (separat von #361 adressiert).
+
+## Offene Fragen / Dinge, die aus den Quellen nicht klar sind
+- Exakte, abschließende Root Cause für alle beobachteten Effekte zum Zeitpunkt des #344-Reverts: **nicht belegbar aus den untersuchten Quellen**.
+- Ob #346 allein sämtliche #334-Anwendungsfälle vollständig ersetzt: **nicht eindeutig belegbar**.
+- Ob #361 funktional unabhängig von allen #334-Problemen ist oder in Randfällen indirekt interagiert: **nicht vollständig belegbar**.
+
+## Quellenliste mit direkten Links
+- PR #334: https://github.com/owasp-modsecurity/ModSecurity-nginx/pull/334
+- PR #344: https://github.com/owasp-modsecurity/ModSecurity-nginx/pull/344
+- Issue #336 Kommentar: https://github.com/owasp-modsecurity/ModSecurity-nginx/issues/336#issuecomment-2612803647
+- PR #326: https://github.com/owasp-modsecurity/ModSecurity-nginx/pull/326
+- PR #273: https://github.com/owasp-modsecurity/ModSecurity-nginx/pull/273
+- PR #346: https://github.com/owasp-modsecurity/ModSecurity-nginx/pull/346
+- PR #361: https://github.com/owasp-modsecurity/ModSecurity-nginx/pull/361
+- ModSecurity Issue #3336: https://github.com/owasp-modsecurity/ModSecurity/issues/3336