Hilfe:Server/HTTP-Komprimierung

HTTP-Komprimierung – Fehleranalyse und Lösung

Diese Seite dokumentiert die Störung der Seitenausgabe am 22. Oktober 2026 und die Korrektur der MediaWiki-seitigen gzip-Einstellung.

Merkmal	Ergebnis
Datum	22.10.2026
Bereich	MediaWiki, HTTP-Antworten, gzip-Komprimierung
Fehlerbild	Unlesbare Zeichen statt einer korrekt dargestellten Wiki-Seite
Ursache / Ansatz	Problem im Zusammenhang mit der MediaWiki-seitigen gzip-Ausgabe
Korrektur	$wgUseGzip von true auf false gesetzt
Ergebnis	Seitenausgabe wieder lesbar; Hauptseite HTTP 200

Fehlerbild

Bei Aufrufen der Perrypedia wurden Seiteninhalte teilweise als unlesbarer Zeichensalat angezeigt. Der Fehler wurde unter anderem auf einem MacBook Air mit Safari und Brave beobachtet, während die Seiten auf iPhones funktionierten.

Die Fehlersuche wurde durch folgende Gegenproben eingegrenzt:

• Fehler in zwei unterschiedlichen Browsern.
• Deaktivierung von Bitdefender-Browsererweiterungen ohne Abhilfe.
• Problem auch ohne Proton VPN sowie über einen iPhone-Hotspot.
• Unterschiedliches Verhalten auf MacBook und iPhones.

Diese Beobachtungen sprachen gegen einen ausschließlich browser- oder netzwerkabhängigen Fehler.

Ursprüngliche Fehlermeldung per E-Mail (anonymisiert)

Die folgende Wiedergabe enthält die technischen Angaben der ursprünglichen Zuschrift; personenbezogene Angaben wurden weggelassen und die Formulierung redaktionell gekürzt.

Guten Tag,

seit dem 22. Oktober 2026 wird die Perrypedia auf meinem
MacBook Air sowohl in Safari als auch in Brave ausschließlich
als unlesbarer Zeichensalat dargestellt.

Betroffene Adresse:
https://www.perrypedia.de/wiki/Hauptseite

Bereits durchgeführte Tests:
- Der Fehler tritt in Safari und Brave gleichermaßen auf.
- Bitdefender-Browsererweiterungen wurden testweise deaktiviert.
- Ohne Proton VPN besteht der Fehler weiterhin.
- Auch über einen iPhone-Hotspot bleibt der Fehler bestehen.
- Auf zwei unterschiedlichen iPhones funktioniert die Seite.
- Selbst in einer Suchmaschinen-Vorschau ist teilweise
  Zeichensalat zu sehen.

Zusätzliche technische Prüfung:
- curl --compressed liefert unlesbare Inhalte.
- Mit Accept-Encoding: identity wird korrektes HTML geliefert.

Bitte die gzip-Komprimierung und die HTTP-Header prüfen.

Diagnose

Im MediaWiki-Konfigurationsverzeichnis /var/www/prod/mediawiki/ war die gzip-Funktion der Wiki-Software aktiviert.

Vor der Korrektur enthielt LocalSettings.php:

<syntaxhighlight lang="php"> $wgUseGzip = true; </syntaxhighlight>

Die vorherige Konfiguration wurde unter folgendem Pfad gesichert:

/root/php83-isolated-test/LocalSettings.pre-gzip-fix-20261022.php

Zusätzlich wurde eine komprimierte Antwort der Hauptseite als Diagnoseartefakt gesichert:

/root/php83-isolated-test/Hauptseite.pre-gzip-fix-20261022.html.gz

Die beobachtete Störung war mit einer fehlerhaften Behandlung der komprimierten HTTP-Ausgabe vereinbar. Die genaue verursachende Schicht (MediaWiki, PHP oder HTTP-Verarbeitung) ist anhand der hier dokumentierten Befunde nicht abschließend isoliert.

Lösung

In der produktiven LocalSettings.php wurde die MediaWiki-eigene gzip-Ausgabe deaktiviert:

<syntaxhighlight lang="php"> $wgUseGzip = false; </syntaxhighlight>

Wichtig: Diese Änderung schaltet nicht zwingend jede HTTP-Komprimierung des Servers ab. Eine separate Komprimierung durch Apache beziehungsweise eine andere HTTP-Schicht kann weiterhin aktiv sein.

Die allgemeine MediaWiki-Einstellung $wgDisableOutputCompression blieb auskommentiert und wurde für diese Korrektur nicht aktiviert.

Funktionsprüfung

Prüfung	Ergebnis
Produktive Einstellung $wgUseGzip	false
Hauptseite	HTTP 200
Seitenausgabe im Browser	Wieder korrekt lesbar gemeldet
HTTP-Antwort auf Anfrage mit Accept-Encoding: gzip	Kann weiterhin Content-Encoding: gzip enthalten

Damit ist die MediaWiki-eigene gzip-Einstellung deaktiviert, nicht jedoch nachweislich die gesamte HTTP-Komprimierung. Die Header einer späteren Anfrage zeigten weiterhin Content-Encoding: gzip.

Rollback

Die ursprüngliche Einstellung ist in der Sicherungsdatei dokumentiert. Ein Rückwechsel würde $wgUseGzip = true; wiederherstellen.

Achtung: Ein Rollback könnte die fehlerhafte Seitenausgabe erneut auslösen. Änderungen nur nach ausdrücklicher Freigabe, vorheriger Sicherung und anschließender Prüfung in mehreren Browsern durchführen.

Hinweise und Nacharbeiten

• Bei erneutem Auftreten HTTP-Header (Content-Encoding, Content-Type, Vary) und tatsächlichen Antwortinhalt gemeinsam prüfen.
• Die Komprimierung durch MediaWiki, PHP und Apache getrennt untersuchen; Mehrfachkomprimierung und falsche Headerzuordnung ausschließen.
• Gegenproben mit und ohne Accept-Encoding: gzip sowie in unterschiedlichen Browsern durchführen.
• Keine pauschale Deaktivierung sämtlicher Serverkomprimierung ohne technische Notwendigkeit.

Siehe auch

• Server – Probleme und Lösungen
• PHP-Sicherheitsupdate vom 21.10.2026