Also wir haben SSL, wurde zum 01.03. über Timme (SSL-Zertifikat Comodo PositiveSSL DV 2 Jahre) neu bestellt. Das war ein paar Tage nach dem Umstieg auf 5.3.
Das andere werde ich mal dem Programmierer übermitteln, mal sehen was er meint…
Danke auch an @lappies. D.h. du benötigst sämtliche Kategorie-URLS und einen Zeitraum für die Überprüfung. Welchen hast du eingestellt? Gibt es da schon interessante Beobachtungen?
Hallo,
ich habe auch die Comodo Zertifikate und von anfang an alles nur über SSL erreichbar.
Mein script läuft alle 5min und hat bischer noch nicht alarm geschlagen. Ich überwache alle Kategorien/Einkaufswelten, bei mir nur 44 Stück an der Zahl. Mir fehlt auch aktuell die Zeit mich da tief einzuarbeiten und zu debuggen, da der fehler nicht da ist wenn ich mal etwas luft habe.
@kci genau, alle Kategorie-URLs und ein zeitraum, z.B. alle 5min, alle 15min oder stündlich etc. Wenn du ein Linuxserver hast worüber du auch mails von der konsole versenden kannst, kann ich dir auch denn script zu verfügung stelle, ist kein hexenwerk.
@Grex
du bist ja schon ein stück weiter gekommen, tritt der fehler den häufig bei dir auf?
Also hier tritt der Fehler mehrmals täglich auf. Ich schaue alle 3-4 Stunden tagsüber und dann geht immer irgendeine Kategorie nicht. Manchmal auch mehrere. Abends lösche ich den Cache, wenn ich morgens schaue geht wieder irgendeine nicht.
Tritt der 404 denn auch ohne HTTP-Cache auf?
Für mich klingt das erstmal danach, dass die Kategorie bei Cache-Aufbau einen 404 zurück gibt, dieser 404 wird im Cache abgelegt und daher wird auch bei jedem späteren Aufruf ein 404 zurückgegeben, bis der Cache geleert wird. Die Frage ist also eigentlich, warum initial hier ein 404 zurück gegeben wird. Typischerweise würde ich vermuten, dass bspw. die Kategorien importiert werden in regelmäßigen Abständen und die Kategorie für die Dauer des Abgleiches inaktiv ist (Vielleicht auch “Kategoriebaum neu aufbauen?”)
Es bringt hier nichts zu debuggen, warum ein 404 zurück kommt, wenn der Fehler schon vorliegt - denn da kommt die Seite aus dem Cache und es wird auch keine Fehlermeldungen und ähnliches dazu geben, denn es wird hier ja der Cache geladen und nicht der eigentliche Request der den 404 erzeugt hat. Somit macht es ur Sinn zu prüfen, warum beim ersten initialen Aufruf der den Cache aufbaut ein 404 entsteht. Den 404 zu reproduzieren, bringt somit eigentlich garnichts beim Debugging.
Dazu würde ich den Cache leeren und dann das Access-Log überwachen - Urzeit anschauen, ab wann es den ersten 404 gibt und dann prüfen, welche Prozesse auf dem Server parallel laufen: Importe/Exporte, Cronjobs, …
Im Zweifel auch mal einen Trigger auf die s_categories.active legen, sowie auf die s_core_rewrite_urls und das mal mitloggen.
Danke, wenn ich nach dem Cache leeren sämtliche Kategorien aufrufe funktionieren alle und dann sind sie nach meinem Verständnis im Cache, also jederzeit abrufbar. Trotzdem tritt der Fehler durch irgendetwas in der Folge auf ohne das der Cache geleert wird, Kategorien importiert, der Index neu aufgebaut oder Cache aufgewärmt wird. Wir haben ja auch bereits sämtliche Cronjobs versuchsweise deaktiviert. Da es auch am Wochenende passiert, wo keiner mit Pickware oder sonstwie im Backend arbeitet muss es doch durch irgendein Nutzerverhalten im Frontend ausgelöst werden (sprich es wird irgendeine Funktion genutzt, die das Problem auslöst) oder? Wir werden ja von einer Agentur mit 10 Jahren Shopware-Erfahrung betreut. Sie haben aktuell noch einen Kunden mit diesem Problem. Zuvor gab es das noch nicht. Wir sind ja zum Glück erst Ende Februar auf 5.3. umgestiegen. Der andere Kunde kämpft schon seit Monaten mit diesem Problem. Er ist inzwischen auf 5.4.
Naja, der Cache wird ja auch invalidiert nach einer Zeit. D.h. nur weil du im Backend den Cache nicht leerst, heißt es nicht, dass der Cache für die Seite nicht neu aufgebaut wird. Der Cache für die jeweiligen Seiten wird beim Speichern im Backend invalidiert, aber auch nach den definierten Zeiten im Performance-Modul. Bei Kategorieseiten sind das bspw. 3600 Sekunden - d.h. jede Stunde wird ohnehin der Cache neu aufgebaut. Du kannst ja mal testweise im Performance-Modul diesen Wert hochsetzen, dann siehst du zumindest, ob die häufigkeit abnimmt.
Ruft denn vielleicht ein Bot initial nach Cache-Invalidierung die Seite auf?
Ich lasse mit Icinga2 (änhlich wie nagios) die Website nun überprüfen, mit Zeitdiagramm & E-Mail Benachrichtigung wann ein 404 auftritt, und ein Status Code 200 mittels check_http.
Ich frage mich für was wir 1200€ bezahlt haben, wenn der E-Mail Support schreibt ich soll das debugging aktivieren, und warten bis ich oder ein Kunde die Fehlermeldung erhalte, widderrum wird hier bestätigt dass das nichts bringt, weils aus dem Cache kommt.
Selbst der Support fühlt sich nicht verantwortlich das Problem genauer unter die Lupe zu nehmen, und schreibt nur Füllsätze, damit halt die SLA erreicht wird. Daher habe ich versucht das ganze selbst zu debuggen, mit PHP kenn ich mich schließlich halbwegs gut aus. Mir bleibt nichts anderes übrig, denn der Kunde kämpft mit dem Problem schon seit gut 2 Monaten und mir nichts anderes übrig bleibt wie es aussieht.
Der Status zwischen 404 und 200 ändert sich innerhalb weniger Minuten, mit oder ohne Cache leeren. (Cache leeren hilft immer), d.h. denke ich nicht, dass es kein Cache Thema ist. Und wieso bei mir nur die Hauptkategorien?, Subkategorien sind nicht betroffen, die sind ja schließlich auch gecached.
Das Problem liegt erst seit Version 5.3, irgendwer muss doch wissen was der Auslöser sein könnte.
1 „Gefällt mir“
Ich frage mich für was wir 1200€ bezahlt haben, wenn der E-Mail Support schreibt ich soll das debugging aktivieren, und warten bis ich oder ein Kunde die Fehlermeldung erhalte, widderrum wird hier bestätigt dass das nichts bringt, weils aus dem Cache kommt.
Vermutungen und Bestätigungen sind erstmal etwas grundverschiedenes. Ich hab mir keinen solchen Fehler bisher angesehen, vermute nur aufgrund des Fehlerbildes. Gerne kannst du mir mal die Ticketnummer per PN schicken, dann kann ich ggf. auch mal draufschauen. Unabhängig davon ist ein sporadischer Fehler stets aufwändig und langwierig zu debuggen.
1 „Gefällt mir“
Konnte das jetzt doch nachstellen, schauen wir uns an: Shopware Issuetracker
1 „Gefällt mir“
Der Grund für das Problem scheint eine Normalisierung der URL an folgenden zwei Stellen im HttpCache zu sein:
https://github.com/shopware/shopware/blob/5.4/engine/Shopware/Components/HttpCache/Store.php#L245
https://github.com/shopware/shopware/blob/5.4/engine/Shopware/Components/HttpCache/Store.php#L275
Der Fix wäre die beiden rtrim() zu entfernen damit die URLs jeweils separat behandelt werden.
Ich muss dass noch genauer testen aber sollte jemand das schon einmal ausprobieren wollen freue ich mich natürlich über jedes Feedback!
2 „Gefällt mir“
Das wäre natürlich klasse, wenn es damit behoben werden könnte. Wir testen das gerne morgen. Was ich noch nicht verstehe ist, wieso haben dann nicht alle Shopware-Installationen dieses Problem? Die Grundeinstellung für Kategorien mit “/” haben ja vermutlich die meisten. Liegt das daran, dass nur bei den Betroffenen scheinbar irgendwelche externen Bots o.ä. auf die Kategorien entgegen der Einstellung ohne das abschließende “/” zugreifen? Weil innerhalb des Shops sollten die Verlinkungen ja mit der Einstellung konform gehen und entsprechend verlinken.
Das wäre natürlich klasse, wenn es damit behoben werden könnte. Wir testen das gerne morgen. Was ich noch nicht verstehe ist, wieso haben dann nicht alle Shopware-Installationen dieses Problem? Die Grundeinstellung für Kategorien mit „/“ haben ja vermutlich die meisten. Liegt das daran, dass nur bei den Betroffenen scheinbar irgendwelche externen Bots o.ä. auf die Kategorien entgegen der Einstellung ohne das abschließende „/“ zugreifen? Weil innerhalb des Shops sollten die Verlinkungen ja mit der Einstellung konform gehen und entsprechend verlinken.
Shopware selbst legt die Links ja so an, wie die in der Datenbank stehen - es wird also nie eine URL ohne / erzeugt, es sei denn, man richtet das so ein. Könnte mir aber vorstellen, dass bspw. ein Kunde irgendwo einen Link ohne / am Ende setzt oder ein Bot das aufruft. Wenn man Unterkategorien hat und bspw. die URL editiert kann das ja auch passieren. Oder man selbst hat irgendwo in einer Kategorie o.ä. einen Link falsch gesetzt.
Ich habe jetzt rtrim entfernt,
Zeile 245:
ALT: return rtrim($request->getUri(), ‘/’);
NEU: return $request->getUri();
Zeile 275:
ALT: return rtrim($uri, ‘/’);
NEU: return $uri;
@hsoebbing bitte um Überprüfung, bin mir nciht sicher ob nun return ($uri); reicht, oder doch return $uri."/"; bzw. return $request->getUri()."/";
Die Methode hier generiert nicht die tatsächliche URL sondern soll unterschiedlich “aussehende” URLs mit derselben Ausgabe (typisches Beispiel: www.meinshop.de/kategorie/?a=b&b=a vs www.meinshop.de/kategorie/?b=a&a=b) normalisieren um doppelte Einträge im HTTP-Cache zu vermeiden. Das sieht man in der Funktion \Shopware\Components\HttpCache\Store::generateCacheKey wo die URL am Ende schlicht nur gehashed wird. Die Slashes am Ende der URL sollten daher nicht gesondert bearbeitet werden, dadurch entstand der Fehler weil ein Aufruf mit Slash am Ende den gleichen Cache abgerufen hat wie eine URL ohne Slash.
Ich bin nicht vom Fach, heißt das jetzt so ist es korrekt?
Zeile 245:
ALT: return rtrim($request->getUri(), ‚/‘);
NEU: return $request->getUri();
Zeile 275:
ALT: return rtrim($uri, ‚/‘);
NEU: return $uri;
@hsoebbing also ist die Änderung wie oben beschrieben aus deiner Sicht so OK? Je früher wir bestätigen können, dass das funktioniert umso schneller kann ein Hotfix oder Update für andere Kundenshops rausgebracht werden.
Es gibt noch eine dritte Stelle, das hier ist die Änderung die aktuell getestet wird:
--- a/engine/Shopware/Components/HttpCache/Store.php
+++ b/engine/Shopware/Components/HttpCache/Store.php
@@ -242,7 +242,7 @@ class Store extends BaseStore
$requestParams = $request->query->all();
if (count($requestParams) === 0) {
- return rtrim($request->getUri(), '/');
+ return $request->getUri();
}
$parsed = parse_url($request->getUri());
@@ -268,11 +268,11 @@ class Store extends BaseStore
$uri = sprintf(
'%s%s%s',
$request->getSchemeAndHttpHost(),
- $path === '/' ? '/' : rtrim($path, '/') . '/',
+ $path,
empty($stringParams) ? '' : "?$stringParams"
);
- return rtrim($uri, '/');
+ return $uri;
}
/**
Da es noch getestet wird kann ich noch nicht abschließend beurteilen ob es ok ist. Allerdings war die Logik ursprünglich ähnlich, das Abschneiden des Slashes ist erst Ende letzten Jahres hinzu gekommen.
Edit: Hier einmal die umgeschriebene Variante, zum einfacheren Copy/Pasten:
private function verifyIgnoredParameters(Request $request)
{
$requestParams = $request->query->all();
if (count($requestParams) === 0) {
return $request->getUri();
}
$parsed = parse_url($request->getUri());
$query = [];
parse_str($parsed['query'], $query);
$params = array_diff_key(
$query,
array_flip($this->ignoredUrlParameters)
);
/**
* Sort query parameters
*/
$stringParams = $this->sortQueryParameters($params);
$path = $request->getPathInfo();
/**
* Normalize URL to consistently return the same path even when variables are present
*/
$uri = sprintf(
'%s%s%s',
$request->getSchemeAndHttpHost(),
$path,
empty($stringParams) ? '' : "?$stringParams"
);
return $uri;
}
1 „Gefällt mir“
Okay, alle drei Stellen sind jetzt geändert. Mal sehen…
Also bis jetzt keine Probleme mehr. Ich gehe davon aus, dass es das war. Puh, danke auch an die @lappies!
1 „Gefällt mir“
Hallo,
auch ich habe seit mehreren Tagen keinen 404 Error mehr erhalten. Zur Info, ich lasse die Website im Minutentakt überwachen.
Danke an Alle beteiligten.
1 „Gefällt mir“