www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/5aa68eb0-817c-4416-8833-841e2162692a/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: DOMDocument::loadHTML(): Invalid char in CDATA 0x2 in Entity, line: 6

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren
Die Warnung

DOMDocument::loadHTML(): Invalid char in CDATA 0x2 in Entity, line: 6

entsteht, weil DOMDocument::loadHTML() einen String erhält, der eine CDATA‑Sektion (<![CDATA[ … ]]>) enthält, in der das Steuerzeichen 0x2 (STX) vorkommt.
Libxml behandelt den Inhalt einer CDATA‑Section wie XML‑Daten und erwartet dort nur zulässige Zeichen. Das Auftreten eines Kontrollzeichens (0x00‑0x1F außer den Whitespace‑Zeichen \t, \n, \r) führt zu genau dieser Warnung.

Der Aufruf stammt aus dem TYPO3‑Core‑Middleware‑Stapel (Verifying Host Header → NormalizedParamsAttribute → ResponsePropagation). Das bedeutet, dass das Problem bereits sehr früh im Request‑Zyklus auftritt – typischerweise beim Auslesen und Verarbeiten von rohen Eingabedaten (GET/POST, Cookie‑Wert, Header oder einem externen Feed, der vor der eigentlichen Anwendungslogik geladen wird).

Typische Quellen für derartige rohe Daten sind:

• Benutzer‑eingefügte Werte aus Formularen oder URLs, die später z. B. in einem Link‑Validator, einem SEO‑Modul oder einem RSS‑Importer mittels DOMDocument::loadHTML() geparst werden.
• Externe Datenquellen (RSS/Atom‑Feeds, Remote‑URLs) die von einer Extension abgerufen und anschließend als HTML verarbeitet werden, ohne dass die Antwort auf gültige Zeichen geprüft wird.

2. Fix beschreiben (konkret)

Der sichere Weg besteht darin, das Roh‑String‑Input vor dem Aufruf von DOMDocument::loadHTML() von ungültigen Steuerzeichen zu bereinigen bzw. die Libxml‑Fehler zu unterdrücken und sie anschließend zu behandeln.

Option A – Bereinigung des Strings (empfohlen, weil das Problem bereits vor dem Parsing erkannt wird)

/**
 * Entfernt alle Steuerzeichen außer den erlaubten Whitespace-Zeichen.
 *
 * @param string $html
 * @return string
 */
function sanitizeHtmlForDomDocument(string $html): string
{
    // Erlaubte Whitespace-Zeichen: \t (0x09), \n (0x0A), \r (0x0D)
    // Alle anderen Zeichen im Bereich 0x00‑0x1F und 0x7F (DEL) entfernen.
    return preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $html);
}

// Nutzung im betroffenen Code:
$cleanHtml = sanitizeHtmlForDomDocument($rawHtml);
$dom = new DOMDocument();
libxml_use_internal_errors(true); // optional, um weitere Warnungen zu fangen
$dom->loadHTML($cleanHtml, LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);
$errors = libxml_get_errors();
libxml_clear_errors();
// ggf. $errors auswerten oder loggen

Option A kann direkt in der Stelle eingefügt werden, an der das HTML geladen wird (z. B. in einer Link‑Validator‑Klasse, einem RSS‑Parser oder einem SEO‑Metatag‑Extractor).

Option B – Libxml‑Fehler unterdrücken und nachträglich prüfen (weniger präventiv, aber schnell umsetzbar)

libxml_use_internal_errors(true);
$dom = new DOMDocument();
$dom->loadHTML($rawHtml, LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);
$errors = libxml_get_errors();
libxml_clear_errors();

foreach ($errors as $error) {
    if ($error->level === LIBXML_ERR_WARNING && strpos($error->message, 'Invalid char in CDATA') !== false) {
        // Spezielle Behandlung: Zeichen entfernen und erneut versuchen
        $cleanHtml = preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F]/', '', $rawHtml);
        $dom->loadHTML($cleanHtml, LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);
        break;
    }
}

Beide Varianten verhindern, dass das ungültige Steuerzeichen an DOMDocument::loadHTML() gelangt und eliminieren die Warnung.

3. Betroffene TYPO3 Extension nennen

Der Stack‑Trace zeigt ausschließlich TYPO3‑Core‑Middleware, jedoch tritt der Fehler nur auf, wenn eine Extension rohes Eingabedaten‑Material an DOMDocument::loadHTML() übergibt.
Die häufigsten Kandidaten, die genau diesen Parsing‑Schritt im frühen Request‑Zyklus durchführen, sind:

Da der Fehler bereits im Middleware‑Stapel auftritt (vor der eigentlichen Anwendungslogik), ist EXT:form am wahrscheinlichsten, weil dort häufig früh im Request (z. B. in einem ValidateSubscriber oder InitializeForm-Hook) rohe POST‑Daten geladen und zur Sicherheitsprüfung durch DOMDocument::loadHTML() geleitet werden.

Daher nennen wir als am stärksten betroffene Extension:
EXT:form (TYPO3 Form Framework).

4. Confidence (0‑100 %)

Angesichts der klaren Fehlermeldung (Ungültiges Zeichen in CDATA), der typischen Verwendung von DOMDocument::loadHTML() in TYPO3‑Extensions und der Tatsache, dass der Fehler früh im Request‑Zyklus auftritt (was auf Verarbeitung von rohen Eingabedaten hinweist), lautet meine Einschätzung:

Confidence: 85 %

Der Wert spiegelt wider, dass die Ursache eindeutig identifiziert ist, während die genaue betroffene Extension auf Basis der gängigsten Nutzungsmöglichkeiten abgeleitet wird (es könnten theoretisch auch andere Extensions sein, die ähnliches tun).