www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/b26bc8ff-9f07-40ef-aee9-aa2745f43eec/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

ErrorException: Warning: file_get_contents(https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Erwe…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers: HTTP 503 Service Unavailable bei externem API-Aufruf¶

1. Ursache identifizieren¶

Der Fehler tritt auf, weil die TYPO3-Anwendung versucht, eine externe API (https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch) via file_get_contents() abzufragen, diese aber mit HTTP 503 (Service Unavailable) antwortet.
Konkrete Gründe:

• Externer Dienst nicht erreichbar:
  Der Zielserver (rietberg.ratsinfomanagement.net) ist entweder:
  • Überlastet oder in Wartung.
  • Blockiert die Anfrage (z. B. durch IP-Filter, Rate-Limiting oder Firewall).
  • Hat temporäre Netzwerkprobleme.
• Fehlende Fehlerbehandlung:
  Die Anwendung prüft nicht, ob der Dienst verfügbar ist, bevor file_get_contents() aufgerufen wird.
• URL-Encoding:
  Die URL enthält einen Umlaut (Führungszeugnis), der korrekt encodiert ist (%C3%BC), aber möglicherweise vom Zielserver nicht verarbeitet wird.

Hinweis aus dem Stacktrace:
Der Fehler stammt aus /public/index.php (Zeile 21), wo vermutlich ein eigener Code (keine TYPO3-Core-Funktion) die API abfragt. Die TYPO3-Core-Klassen (AbstractApplication, MiddlewareDispatcher) sind nur indirekt betroffen, weil sie den Request verarbeiten.

2. Fix beschreiben (konkret)¶

Kurzfristige Lösung (Fehlerbehandlung):

• Prüfen, ob der Dienst verfügbar ist, bevor file_get_contents() aufgerufen wird:

  $url = 'https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Erweitertes%20F%C3%BChrungszeugnis';
  $context = stream_context_create([
      'http' => [
          'timeout' => 5, // Timeout in Sekunden
          'ignore_errors' => true, // HTTP-Fehlercodes nicht als Exception werfen
      ],
  ]);
  
  // Verfügbarkeit prüfen (HEAD-Request)
  $headers = @get_headers($url, 1);
  if ($headers === false || strpos($headers[0], '200') === false) {
      // Fallback: Cache nutzen oder Fehlermeldung anzeigen
      throw new \RuntimeException('Externer Dienst ist nicht verfügbar (HTTP 503).');
  }
  
  // Daten abrufen
  $response = @file_get_contents($url, false, $context);
  if ($response === false) {
      throw new \RuntimeException('Fehler beim Abrufen der Daten: ' . error_get_last()['message']);
  }
  

Mittelfristige Lösung (Robustheit):

• Caching implementieren:
  • Antworten der API zwischenspeichern (z. B. mit TYPO3-Cache oder Redis), um bei Ausfällen auf alte Daten zurückzugreifen.
  • Beispiel mit TYPO3-Cache:

    $cache = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Cache\CacheManager::class)->getCache('my_cache');
    $cacheIdentifier = md5($url);
    
    if ($cache->has($cacheIdentifier)) {
        $response = $cache->get($cacheIdentifier);
    } else {
        $response = file_get_contents($url, false, $context);
        $cache->set($cacheIdentifier, $response, [], 3600); // 1 Stunde Cache
    }
    

• Alternative HTTP-Clients nutzen:
  • Statt file_get_contents() den Guzzle HTTP-Client verwenden (bessere Fehlerbehandlung, Zeitüberschreitungen, Retries):

    $client = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\GuzzleHttp\Client::class);
    try {
        $response = $client->get($url, [
            'timeout' => 5,
            'connect_timeout' => 2,
        ]);
        $data = $response->getBody()->getContents();
    } catch (\GuzzleHttp\Exception\ServerException $e) {
        // HTTP 5xx-Fehler behandeln
        throw new \RuntimeException('Externer Dienst antwortet mit Fehler: ' . $e->getMessage());
    }
    

• Fallback-Logik:
  • Bei Fehlern eine statische JSON-Datei oder eine lokale Datenbank als Fallback nutzen.

Langfristige Lösung (Architektur):

• Asynchrone Verarbeitung:
  • API-Aufrufe in einen Queue-Worker (z. B. TYPO3-Scheduler) auslagern, um die Frontend-Performance nicht zu blockieren.
• Monitoring:
  • Einen Health-Check für die externe API einrichten (z. B. mit TYPO3-Extension "healthcheck" oder externem Tool wie UptimeRobot).

3. Betroffene TYPO3 Extension¶

Der Fehler stammt nicht aus einer TYPO3-Core-Extension, sondern aus eigenem Code in /public/index.php.
Mögliche Kandidaten für die Extension:

• Eine selbst entwickelte Extension, die die API abfragt (z. B. für ein Formular oder eine Suche).
• Eine Drittanbieter-Extension, die mit dem Ratsinformationssystem von Rietberg interagiert (z. B. eine "Ratsinfo"-Extension).

Empfehlung:

• Den Code in /public/index.php prüfen und in eine eigene Extension auslagern (z. B. ext:my_api_integration).
• Die Extension sollte:
  • Einen Service für die API-Kommunikation bereitstellen.
  • Konfigurierbare Timeouts und Cache-Einstellungen haben.
  • Logging für fehlgeschlagene Aufrufe implementieren.

4. Confidence (0–100%)¶

• Ursache: 95% (HTTP 503 ist klar, aber die genaue Ursache auf Serverseite unbekannt).
• Fix: 90% (Die vorgeschlagenen Lösungen sind bewährte Patterns, aber die Implementierung hängt vom Projekt ab).
• Extension: 80% (Der Fehler stammt aus eigenem Code, aber die genaue Extension ist ohne weiteren Kontext nicht sicher identifizierbar).

Zusammenfassung¶

Nächste Schritte:

1. Den Code in /public/index.php analysieren und in eine Extension auslagern.
2. Die API-Abfrage mit Guzzle und Caching umschreiben.
3. Einen Health-Check für die externe API einrichten.