Caching, also das Zwischenspeichern von einmal ausgelieferten Seiten, hat viele Vorteile. Insbesondere, wenn das Generieren von Seiten einen hohen Rechenaufwand erfordert oder die Seite sehr viele Besucher bekommt, ist das Zwischenspeichern der Seite ein probates Mittel, um Last vom Server zu nehmen. Dies hat auch positive Auswirkungen auf die Ladezeit.
Doch falsch eingesetzt, kann Caching auch zu Problemen führen. In diesem Fall drohte einem Kunde, die Sichtbarkeit und somit Reichweite seines Podcasts zu verlieren. Denn sein RSS-Feed meldete einen Status 304 - Not Modified und einen leeren Inhalt.
In einem der letzten Projekte sollte eine Site aktualisiert werden, die recht erfolgreich Podcasts veröffentlicht. Diese Site setzte aber das veraltete Plugin PodPress zum Verwalten der Podcasts ein. Dieses Plugin wird seit vielen Jahren nicht mehr gewartet und aktualisiert, sollte deswegen also nicht mehr eingesetzt werden. Gerade im deutschsprachigen Bereich ist das WordPress-Plugin Podlove Podcast Publisher sehr beliebt und auch sehr mächtig.
Auf dieses Plugin sollte nun migriert werden, ohne dass die Bestandsdaten und insbesondere die Podcasts verloren gehen. Ein großer Fokus lag auch darauf, dass die Migration möglichst ausfallfrei geschieht, damit das aufgebaute Renommee bei den Hörern, aber auch iTunes als zentraler Podcast-Katalog nicht verloren geht.
Ein Upgrade mit Folgen
Um die Migration möglich zu machen, hat der Kunde sein Webhosting-Paket bei dem Anbieter Domainfactory aktualisiert. Jahrelang war er auf einem alten Tarif. Damit der Wunsch um nahtlose Übernahmen erfüllt werden kann (und generell die Migration technisch einfacher wird), war ein SSH-Zugriff nötig, um damit WP-CLI nutzen zu können.
Da das Upgrade eh im Raum stand, war der Zugriff schnell eingerichtet.
Einige Tage später meldeten sich erste Hörer des Podcasts, dass ihre App zum Verwalten der Podcasts (sogenannte Podcatcher) keine Episoden mehr anzeigten – der Feed war leer. In den Podcatchern wird ein RSS-Feed der Website abonniert und von diesem die aktuellen Episoden ausgelesen.
Die Hörer waren technisch affin und fanden heraus, dass der Server den HTTP-Statuscode 304 - Not Modified ausspielte – und keinen weiteren Inhalt.
Grundsätzlich ist der Statuscode 304 durchaus hilfreich, schließlich muss der Webserver nicht immer und immer wieder den gleichen Inhalt generieren. Doch in diesem Fall wurde kein weiterer Inhalt ausgeliefert und die Podcatcher verloren ihre Inhalte. Es drohte zusätzlich, dass iTunes als zentraler Podcast-Katalog dies ebenfalls feststellt und den Podcast aufgrund dessen aus dem Index werfen würde.
Das Phänomen war mal mehr, mal weniger nachvollziehbar, aber auf jeden Fall existent. Das zeigten wiederholte Abfragen des HTTP-Headers mit Hilfe von websniffer.cc, das die HTTP-Header schnell und ohne Plugins aufzeigt.
Auffällig war, dass die angegebene Server-Software nginx sein sollte, obwohl der Kunde sehr sicher Apache als Webserver einsetzt. Wie kommt es also dazu, dass hier nginx eingreift – eine schlanke und moderne Webserver-Software, die dennoch hier nicht sein sollte? Der Kunde war überzeugt davon, in den letzten Tagen und Wochen keine Veränderungen am Caching vorgenommen zu haben.
Caching als Service – gut und schlecht zugleich
Die Recherche ergab, dass Domainfactory bereits seit 2020 ihre Webspace-Pakete automatisch nginx als Proxy vor die Websites der Kunden etabliert. Ein Proxy-Server ist ein eigener Server, der noch vor die Websites geschaltet wird und Cachingfunktionen übernehmen kann.
Das ist eine durchaus gute Situation für beide Seiten: domainfactory spart Ressourcen und der Kunde kann sich über schnellere Seiten freuen, weil der nginx-Server bestimmte Anfragen von sich aus beantwortet.
In diesem Fall führte dies aber zu verstärkten Problemen beim Ausliefern des RSS-Feeds. Glücklicherweise bietet der Hoster auch an, diese Funktionalität abzuschalten.
Mit Hilfe der folgenden Zeile in der .htaccess der Webpräsenz kann man das Caching übergangsweise deaktivieren.
Header always set Cache-Control: s-maxage=0
Das ist, zugegebenermaßen, eine recht radikale Lösung, schließlich schaltet man damit den Cache für die gesamte Site ab.
Aber nach Setzen der Zeile ist das Caching erst einmal deaktiviert und der RSS-Feed wurde wieder verlässlich ausgespielt. Nun ist also ausreichend Zeit, Detailkonfigurationen zu tätigen, um einerseits den RSS-Feed vom Caching auszuklammern, andererseits den anderen Seiten dennoch ein Caching zukommen zu lassen.
Fazit
Caching und davor geschaltete Proxy-Server haben häufig große Vorteile, aber nachdem sie aktiviert wurden, sollten alle kritischen Funktionen einer Website sehr detailliert getestet werden, um Fehler zu vermeiden.
Voraussetzung dafür ist, dass man weiß, dass diese Funktionalitäten aktiviert wurden – gerade, wenn man ein Upgrade eines Pakets bucht. Hier scheint domainfactory noch Verbesserungsbedarf in der Kommunikation zum Kunden zu haben.
In diesem konkreten Fall gab es glücklicherweise weder einen Rausschmiss aus dem Katalog von iTunes noch hat man Abonnenten verloren. Und die Migration von PodPress auf Podlove Publisher lief auch reibungslos und ohne Ausfälle.