HTTP 500 Fehler nach Shopware-Update 6.6.10.3 bei Verwendung von Redis mit PayPal- und Amazon Pay-Plugins

Shopware 6 (German)
1

Hallo zusammen,

nach dem letzten Shopware-Sicherheitsupdate (Version 6.6.10.3) treten bei mir HTTP 500-Fehler auf den Account-Seiten auf, wenn sowohl das PayPal-Plugin (v9.7.4) als auch das Amazon Pay-Plugin (v10.2.0) aktiviert sind und Redis verwendet wird.​

Interessanterweise funktionierte diese Konfiguration vor dem Update einwandfrei.​

Ich habe festgestellt, dass die Seiten wieder erreichbar sind, wenn ich entweder Redis deaktiviere oder eines der beiden Plugins deaktiviere.​

Die Server-Logs liefern leider keine spezifischen Hinweise auf die Ursache des Problems.​

Hat jemand von euch ähnliche Erfahrungen gemacht oder kann Hinweise zur Lösung des Problems geben?

Vorab vielen Dank für eure Beteiligung!

2

Hast du Redis mal geleert? Hört sich nach einem Cache Problem an.

3

Hallo,

vielen Dank für den Hinweis bezüglich des Redis-Caches.​

Ich habe bereits den Redis-Cache sowohl über das Backend (Einstellungen > System > Caches & Indizes) als auch über die Konsole mit redis-cli FLUSHALL geleert. Zusätzlich habe ich ein Deployment-Skript verwendet, das den Symfony-Cache löscht, Redis leert und das Theme neu kompiliert. Trotz dieser Maßnahmen bestehen die HTTP 500-Fehler auf den Account-Seiten weiterhin.

Nur das Deaktivieren von Redis oder eines der Plugins behebt das Problem.

4

Selbe Konfiguration hier. Managed vServer bei Timme. Ich kann keine derartigen Probleme bei uns feststellen.
Da muss noch etwas anderes mit rein spielen.

5

Danke für die Rückmeldung.
Verwendet ihr zusätzlich auch Varnish?

Ich werde nachher mal ein neues 1:1 Abbild vom Liveshop auf unserem Testsystem einspielen. Es müsste zwar eigentlich alles identisch sein, aber wir haben zwischenzeitlich 2 Plugins entwickelt, die zwar derzeit inaktiv sind, aber vielleicht hat es im Zusammenhang der Entwicklung noch außerhalb der Plugin-Verzeichnisse eine Änderung gegeben, die ich nicht auf dem Schirm habe und die evtl. für die Probleme verantwortlich ist.

6

Hi,
nein, kein Varnish. Nur Redis.

7

Ich konnte das Problem inzwischen eingrenzen.

Die Ursache liegt in der erweiterten http_cache.reverse_proxy-Konfiguration in der z-shopware.yaml, die mit Shopware 6.6.10.x eingeführt wurde.

Wenn man die Konfiguration wie folgt erweitert:

shopware:
    http_cache:
        reverse_proxy:
            enabled: true
            ban_method: "BAN"
            hosts: [ "http://127.0.0.1:6081" ]
            max_parallel_invalidations: 3
            use_varnish_xkey: true

…funktioniert der gesamte Shop bis auf die Account-Seiten. Diese werfen einen Fehler 500, obwohl im Varnish pass gesetzt und die Anfrage korrekt an das Backend weitergegeben wird.
In der Apache-Fehlerlog erscheinen „Premature end of script headers“ – was auf ein Problem im Zusammenspiel mit den Cache-Headern hindeutet.

Mit dieser simpleren Konfiguration hingegen funktioniert der gesamte Shop einwandfrei:

shopware:
    http_cache:
        reverse_proxy: true

Setzt man jedoch nur:

shopware:
    http_cache:
        reverse_proxy:
            enabled: true

…dann ist gar keine Seite mehr erreichbar.

Hintergrund zur Konfiguration:
Ich entwickle aktuell ein Plugin zur gezielten Cache-Invalidierung bei dynamischen Produktgruppen (also Streams). Ziel ist es, nach Änderungen in einem Produktstream die betroffenen Redis- und Varnish-Caches automatisch zu invalidieren – ohne flushall.

Dazu nutze ich Redis zum gezielten Entfernen relevanter Keys (z. B. product_stream_result_, cms_page_resolver_category_) und Varnish mit aktiviertem xkey, um betroffene Seiten zu bannen.

Dabei zeigte sich allerdings ein weiteres Problem:
Selbst bei sauberer Key-Invalidierung bleiben alte Ergebnisse im Frontend bestehen – offenbar, weil Shopware die Produktstream-Ergebnisse tiefer cached, als dokumentiert. Nur ein kompletter Redis-Flush (flushall) bringt aktuell zuverlässig die gewünschten Resultate – was für einen Liveshop natürlich nicht akzeptabel ist.

Wir haben den Fall auch hier auf GitHub dokumentiert:
:backhand_index_pointing_right: Dynamic Product Groups not updating in storefront (cache/tag invalidation ineffective) · Issue #8221 · shopware/shopware · GitHub

Vielleicht hilft dieser Hinweis auch anderen, die Varnish/Redis im produktiven Einsatz haben und Probleme mit dynamischen Inhalten oder dem neuen Cache-Verhalten nach dem Sicherheitsupdate feststellen.