Projekt

Allgemein

Profil

Aktionen

Bug #301

offen

[Bugsink] InvalidArgumentException: The offset must be a positive integer

Von Bug Sink vor 27 Tagen hinzugefügt.

Status:
Neu
Priorität:
wichtig
Zugewiesen an:
-
Beginn:
25.09.2026
Abgabedatum:
% erledigt:

0%

Geschätzter Aufwand:

Beschreibung

Bugsink: https://bugsink.cytrus.de/issues/issue/3c92831a-5c60-48fb-9b45-834be5c37d16/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

InvalidArgumentException: The offset must be a positive integer


Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers: InvalidArgumentException: The offset must be a positive integer


1. Ursache identifizieren

Der Fehler entsteht im TYPO3 Core-Middleware-Stack, konkret im Bereich der Request-Verarbeitung. Die Aufrufkette zeigt:

VerifyHostHeader::process() → NormalizedParamsAttribute::process() → ResponsePropagation::process()

Wahrscheinlichste Root Cause:

Der Fehler tritt auf, weil die trustedHostsPattern-Konfiguration in $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] entweder nicht gesetzt, leer oder ungültig ist. Wenn VerifyHostHeader::process() (Zeile 55) versucht, den Host-Header des eingehenden Requests gegen dieses Pattern zu validieren (vermutlich mittels preg_match), schlägt die Validierung fehl oder liefert kein erwartetes Ergebnis-Array. Anschließend versucht NormalizedParamsAttribute::process() (Zeile 44), auf ein Array-Element mit einem nicht-positiven Integer-Offset zuzugreifen – z. B. weil ein preg_match-Ergebnis leer ist oder ein Rückgabewert null/false ist und als Array-Index verwendet wird.

Konkretes Szenario:

// In NormalizedParamsAttribute::process() oder aufgerufener Methode:
// Ein Array wird mit einem Offset accessiert, der kein positiver Integer ist
// z.B. durch fehlende/null Werte aus der Request-Parametrierung
$request->getAttribute('normalizedParams')[$invalidOffset]; // $invalidOffset ist kein int > 0

Dies ist kein Extension-Bug, sondern ein TYPO3 Core-Problem (cms-core), das durch fehlende/mismatchende Konfiguration ausgelöst wird.


2. Fix (konkret)

Schritt 1 – trustedHostsPattern konfigurieren:

In der LocalConfiguration.php oder über das Install Tool sicherstellen:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = '.*';

(Oder ein spezifisches Regex-Muster entsprechend der Domain verwenden, z. B. '^www\.example\.com$')

Schritt 2 – Host-Header prüfen:

Stellen Sie sicher, dass der eingehende HTTP-Request einen gültigen Host-Header enthält. Fehlende oder leere Host-Header (z. B. bei CLI-Requests oder falsch konfigurierten Reverse-Proxies) lösen diesen Fehler aus.

Schritt 3 – Site-Configuration prüfen:

Überprüfen Sie die Site-Configuration unter config/sites/<siteIdentifier>/config.yaml:

base: 'https://www.example.com/'
baseVariants: ~

Stellen Sie sicher, dass base gesetzt und korrekt ist.

Schritt 4 – (Workaround falls Core-Bug):

Falls nach Konfigurationskorrektur der Fehler weiterhin besteht, kann ein temporärer Workaround in public/index.php vor dem Bootstrap helfen:

// Vor dem Bootstrap:
if (empty($GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'])) {
    $GLOBALS['TYPO3_CONF_VARS']['SYS']['trustedHostsPattern'] = '.*';
}

Langfristiger Fix: Core-Update auf eine TYPO3-Version, in der dieser Fehler behoben wurde (prüfen Sie changelog.typo3.org nach dem spezifischen Issue in cgl/VerifiedHostHeader oder NormalizedParamsAttribute).


3. Betroffene TYPO3 Extension

TYPO3 Core (typo3/cms-core) – betroffene Dateien:

  • vendor/typo3/cms-core/Classes/Middleware/VerifyHostHeader.php
  • vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php

Keine Dritterweiterung (Extension) ist direkt betroffen. Der Fehler liegt im Core-Middleware-Stack. Allerdings kann eine benutzerdefinierte Extension (z. B. eine Custom-Site-Handling-Erweiterung, die den Request manipuliert oder eigene Middleware einfügt) das Problem indirekt auslösen, indem sie den Host-Header oder die Request-Attribute vor der Core-Verarbeitung verändert.


4. Confidence

Confidence: 80%

Begründung: Die Analyse stützt sich auf den klaren Stack-Trace durch die TYPO3 Core-Middleware (VerifyHostHeader → NormalizedParamsAttribute), die spezifische Fehlermeldung über nicht-positive Integer-Offsets (typisch für Array-Zugriff mit fehlerhaften Schlüsseln aus Regex-Ergebnissen), und das Fehlen von Custom-Extension-Code im Stack-Trace. Die trustedHostsPattern-Fehlkonfiguration ist der häufigste Auslöser dieses spezifischen Fehlers in TYPO3 v12/v13. Die 20% Unsicherheit entsteht durch die Möglichkeit eines spezifischeren Core-Bugs in der verwendeten TYPO3-Version, der eine andere genaue Zeilenursache haben könnte.

Nichts anzuzeigen

Aktionen

Auch abrufbar als: Atom PDF