Reverse Proxy Error (?)

danke für den hinweis. cache-invalidierung war bei mir aber immer deaktiviert, fehler meldung w.o. erschien trotzdem immer.

Hmmm, PHP 7 läuft doch bei Mittwald bereits mit Ioncube. Ich habe leider auch diesen Fehler…

Dem kann ich nur zustimmen, auch bei mir taucht der Fehler auf, egal ob die Cache Invalidierung aktiv ist oder nicht.

danke coarsy für den hinweis mit php 7. eigentlich wollte mich mittwald informieren wenn php 7 mit ioncube möglich ist. habe eben angefragt und nachfolgende nachricht erhalten. ich lasse jetzt mal umstellen.

 

_die automatische Integration des IoncubeLoaders in PHP 7 ist leider weiterhin noch nicht möglich. Gerne teile ich Ihnen aber mit, dass wir Ihnen den IoncubeLoader manuell für Ihr PHP 7 aktivieren können.

Sofern Sie bereits einen Account mit PHP 7 im Einsatz haben, können Sie uns den Account gerne nennen und dann können wir den IoncubeLoader für Sie aktivieren_
.

Hmmm, ich habe dort einen dedizierten Server und die Nachricht im Ticketsystem, dass PHP 7 mit Ioncube bereits zur Verfügung steht. Mich hält aktuell die wahrscheinliche Inkompatibilität von AmazonPayments mit PHP 7 davon ab.

LG,

Chris

ich habe eine vserver dort…liegt vielleicht daran. wie auch immer, habe die umstellung angordert. in einem shop habe ich auch amazonpayments…ich teste es dann mal und berichte

Oja, würde mich freuen, wenn Du berichtest, aber ob die PHP-Version jetzt was mit dem „Reverse proxy returned invalid status code“ zu tun, bezweifele ich doch glatt, zumal dieser auch beim Cache leeren aus dem Backend heraus auftritt.

das bezweifel ich auch. hatte einen shop vor einiger zeit testweise mit php7 ohne ioncube und der revers eproxy fehler bestand weiterhin

Hast Du einen BAN Request vorliegen? Ich mache parallel mal ein Ticket bei Mittwald auf und frage nach, wieso der Server nen falschen Status Code zurückgibt.

1 Like

nein , habe ich nicht. gute idee mit dem ticket, bin gespannt was geantwortet wird. mir konnte man bislang nicht helfen…

hallo chris,

 

so, konnte eben php7 mit ioncubeloader in meinen shops aktivieren. proxy problem besteht - wie erwartet - weiterhin. aber die performance-steigerung gegenüber php 5.6 ist deutlich merkbar, feine sache :slight_smile:

zu amazonpayments: funktioniert in meinem anderen shop mit php7 ! 

hast du schon eine antwort auf dein ticket erhalten ?

 

gruß, bernd

Mich würde auch interessieren, was Mittwald dazu gesagt hat. Ich habe das gleiche Problem.

 

Vielen Dank!

 

Simon

Hallo Simon, eröffne doch auch mal ein Ticket bei Mittwald.Leider meldet sich Coarsy ( s.o.) nicht mehr. Ich habe das Problem im Produktivmodus immer noch, laut Mittwald bin ich aber anscheinend der Einzige und das Problem läge an der Shopware-Programmierung (?) . Da ich im Produktivmodus aber noch ganz andere Fehler habe ( Javascript-Anzeige in Google-SERP obwohl das angeblich mit 5.2.9 behoben wurde), Anzeige Proukte im Mini-Warenkorb geht ab und an nicht…etc.pp…laufen meine Shops ohne all diese Probleme im Bearbeitungsmodus. Statt 0,7s halt eine Ladezeit von 0,9s …damit kann ich leben :slight_smile:

HTTP-Cache und die unmögliche Bilderverwaltung sind meiner Meinung nach die Schwachstellen bei Shopware, alles andere aber sehr gut.

 

Gruß, Bernd

Hallo zusammen,

Mittwald hat mir nun geantwortet: 

wir haben zwischenzeitlich diverse Test durchgeführt
und können die Problematik in einer Standardinstallation nicht nachvollziehen.

Da es sich in Ihrem Fall um eine manuelle Installation von Shopware handelt,
welche also nicht über unseren Softwaremanager durchgeführt wurde,
müssen wir aktuell davon ausgehen, dass die von Ihnen beschriebene Problematik
mit dieser manuellen Installation in Verbindung steht.

Ich bin als weiterhin ratlos und dankbar für weitere Tipps!

Simon

 

Hi @foodloose‍ bin auch bei Mittwald auf PHP 5.6

Habe auch Fehlermeldungen des Reverse Proxy, allerdings nur im Zusammenhang mit der autoamtischen Cache Invalidierung - Clear Cache generell geht.

 

Habt ihr versucht, die CSRF Protection probeweise abzuschalten ? 

In Euren Fehlermeldungen finden sich zumindest entsprechende Hinweise auf das CSRF Token.
Häufig sind Zahlungsanbieter-Plugins die Ursache.

Siehe CSRF Protection

Seit update auf 5.2.14 besteht der Fehler nicht mehr, keine Fehlemeldung. Endlich :-) 

Ich kann das bestätigen. Bei mir erscheint der Fehler inzwischen auch nicht mehr. Habe auch auf 5.2.14 aktualisiert.

Für alle anderen: Mittwald hatte mir heute nochmals geschrieben:

…wir konnten letztendlich doch noch den Hintergrund der Fehlermeldung ermitteln.

In der Datei engine/Shopware/Components/HttpCache/AppCache.php
gibt es eine Sicherheitsfunktion, die prüft ob eine Cacheleerung auch tatsächlich autorisiert ist.
Dazu werden IP Adresse von Server und Client verglichen.
Problematisch ist im Hostingbetrieb, dass die interne Server IP (‚SERVER_ADDR‘) nicht gleich der externen Server IP (‚REMOTE_ADDR‘) ist.

Als Workaround kann nun in der Datei in Zeile 291 geändert werden von:
if ($request->server->get(SERVER_ADDR’) == $request->getClientIp()){ 
in
if ($request->server->get(‚REMOTE_ADDR‘) == $request->getClientIp()){ 

ACHTUNG: Dies ist eine Änderung des ShopwareCores und somit keine dauerhafte Änderung. Bei einem Update wird diese wieder überschrieben.

Viele Grüße

1 Like

danke für die info, ich wäre froh mittwald hätte mir dies mal in meinem ticket auch mitgeteilt :slight_smile:

 

wie gesagt, funktioniert seit 5.2.14 obwohl immer noch if ($request->server->get(SERVER_ADDR’) == $request->getClientIp()){  dirnsteht.

Hallo zusammen,

ich wärme ungern schon ältere Threads auf aber auf der Suche nach einer Lösung zu meinem Fehler bin ich hierauf gestoßen- sonst war die Ausbeute eher mager. Beim Ausführen des CronJobs zum Cache aufwärmen hatte ich immer den hier genannten Reverse Prory Error in den Logs:

[2017-12-11 03:23:15] core.ERROR: Reverse proxy returned invalid status code {"uid":"0ac8c89"}

Der Job zum Cache aufwärmen läuft etwa 30 Minuten nach dem HTTP Cache löschen Job. Der hier beschriebene Workaround greift auch bei mir. Ist allerdings auch “nur” ein Workaround.

if ($request->server->get(SERVER_ADDR') == $request->getClientIp()){ 
in
if ($request->server->get('REMOTE_ADDR') == $request->getClientIp()){ 

Wir nutzen Shopware 5.3.4 als Community Edition. Derzeit sind wir noch in der Einarbeitungsphase und der Shop ist noch nicht online. Gerne würde ich das Problem vor Livegang lösen.

Gibt es hierzu neue Erkenntnisse? Kann mir vielleicht jemand weiter helfen?

Danke & Gruß