---
title: "ADR-0016: Die öffentliche RequestFactory als URI-Grenze"
manual: "HTTP Guard"
version: "0.1.4"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-http-guard:adr-0016@0.1.4"
source: "Adr/ADR-0016-PublicRequestFactoryBoundary.rst"
rendered: "2026-10-18T14:31:43+00:00"
---

# ADR-0016: Die öffentliche RequestFactory als URI-Grenze {#adr-0016}

-   *Status:* Angenommen
-   *Datum:* 2026-10-10
-   *Bezug:* Ergänzt ADR-0003; dessen Middleware- und Transportgrenzen bleiben.

## Kontext {#adr-0016-context}

Ein PSR-7-URI-Objekt kann Informationen aus der ursprünglichen Zeichenfolge
bereits verloren haben. Eine Prüfung erst in der Middleware kann solche
Eingaben nicht rückwirkend unterscheiden. Der registrierte TYPO3-Pfad muss
deshalb die rohe URI vor der Core-Verarbeitung prüfen. Die öffentliche
`TYPO3CMSCoreHttpRequestFactory` ist dafür der Einstieg;
die interne `GuzzleClientFactory` wird nicht ersetzt.

Core 13 und Core 14 unterscheiden sich bei `readonly`. Eine
Versionsnummer allein belegt keine passende Elternklasse. Auch eine fremde
Objektregistrierung oder unterschiedliche Factory-Instanzen würden die
nachgewiesene Grenze verändern.

## Entscheidung {#adr-0016-decision}

[`ext_localconf.php`](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/ExtensionArchitecture/FileStructure/ExtLocalconf.html#file-extension-ext-localconf-php) registriert die zur tatsächlichen Core-Form passende
`GuardedRequestFactory13` oder `GuardedRequestFactory14`,
sofern noch keine fremde Registrierung vorliegt. Die Registrierung wird
vor jedem Aufruf überprüft, auch in Disabled; ein Konflikt wird nicht
überschrieben oder still akzeptiert. Core-Factory und PSR-Factory müssen
dieselbe erwartete Instanz liefern.

`RequestFactoryCompatibility` prüft unterstützte Version,
Sichtbarkeit, Vererbbarkeit, Rückgabetyp, Parameter und Konstruktor vor dem
Laden der Ersatzklasse. Die Form mit `readonly` muss zum Core-Zweig
passen. Die öffentliche Aufrufsignatur bleibt erhalten.

`RawRequestGuardTrait` prüft die rohe URI in Enforce vor der
PSR-7-Verarbeitung. Observe meldet eine Ablehnung, delegiert aber weiterhin;
Disabled überspringt die rohe Policyprüfung. Anschließend delegiert die
Ersatzklasse an die ursprüngliche Core-Factory. Die Middlewareordnung,
Core-Kontextregeln und der kontrollierte terminale Transport aus
[ADR-0003: Zwei Middlewaregrenzen und ein kontrollierter terminaler Transport](https://docs.typo3.org/permalink/netresearch/nr-http-guard:adr-0003@0.1.4) bleiben zusätzliche Grenzen.

## Verworfene Alternativen {#adr-0016-alternatives}

-   **Nur PSR-7-Middleware:** kann zuvor verlorene Rohinformationen nicht prüfen.
-   **Interne GuzzleClientFactory ersetzen:** bindet die Erweiterung unnötig
    an eine interne Core-API und ersetzt mehr als die benötigte URI-Grenze.
-   **Eine Ersatzklasse für beide Core-Zweige:** ignoriert unterschiedliche
    Vererbungsregeln bei `readonly`.
-   **Nur Versionsnummer oder jede fremde Registrierung akzeptieren:** belegt
    weder die tatsächliche ABI noch die aktive Factory-Identität.

## Konsequenzen {#adr-0016-consequences}

Die registrierte Core-Factory erhält eine frühere Validierungsgrenze ohne
einen zweiten HTTP-Stack. Inkompatible ABI oder widersprüchliche Registrierung
führen zum kontrollierten Fehler. Projekte mit eigener Factory-Ersetzung
brauchen eine ausdrückliche Integration; frühe Bootstrap-Aufrufe,
unabhängige Clients und direkte Sockets bleiben außerhalb dieser Grenze.
Bei bereits erzeugten PSR-18-Requests bleibt die Verantwortung für die rohe
URI beim Aufrufer, siehe [Roh-URLs und PSR-7](https://docs.typo3.org/permalink/netresearch/nr-http-guard:api-raw-uri@0.1.4) und [Abdeckung und Vertrauensgrenze](https://docs.typo3.org/permalink/netresearch/nr-http-guard:security-coverage@0.1.4).

## Quellen und Nachweis {#adr-0016-verification}

Die aktuelle Umsetzung steht unter `Classes/Http/` in
`RequestFactoryCompatibility.php`, `RawRequestFactoryRegistration.php`,
`RawRequestGuardTrait.php` und den beiden Ersatzklassen; die Verdrahtung
steht in [`Configuration/Services.yaml`](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/ExtensionArchitecture/FileStructure/Configuration/ServicesYaml.html#file-extension-configuration-services-yaml) und [`ext_localconf.php`](https://docs.typo3.org/m/typo3/reference-coreapi/14.3/en-us/ExtensionArchitecture/FileStructure/ExtLocalconf.html#file-extension-ext-localconf-php).

`Tests/Unit/RequestFactoryCompatibilityTest.php`,
`Tests/Unit/RequestFactoryAbiContractTest.php` und
`Tests/Unit/RawRequestFactoryModeTest.php` prüfen ABI, Registrierung und
Modusgrenzen. Die echten Core-/Bootstrap-Nachweise stehen getrennt unter
[Dokumentierte Prüfstände](https://docs.typo3.org/permalink/netresearch/nr-http-guard:verification-report@0.1.4) und `Tests/Functional/production-bootstrap.php`.
Dieser ADR dokumentiert die heute geprüften Quellen; seine Erstellung ist
kein neuer Lauf dieser Tests und keine neue Native-Messung.

## Anlass für Neubewertung {#adr-0016-reassessment-trigger}

Eine Änderung der öffentlichen Core-Signatur, Vererbung, Registrierung oder
PSR-Aliasverdrahtung verlangt erneute ABI- und Bootstrap-Prüfung. Eine
erweiterte Abdeckungszusage braucht Nachweise für den zusätzlichen Pfad.
