# HTTP Cache löschen ohne Auswirkungen?
**URL:** https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605
**Category:** Allgemein
**Created:** [7. Oktober 2018 um 14:13 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605 "2018-10-07T14:13:50Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 14:13 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/1 "2018-10-07T14:13:50Z")
Wir löschen in unseren Shopware-Installationen einmal pro Nacht den HTTP Cache via **Shopware\_CronJob\_ClearHttpCache**. Dabei werden die Cronjobs direkt über die Console mit **bin/console sw:cron:run** ausgeführt. Die Ergebnisdaten des Cronjobs sind **Cleared HTTP-Cache** , also positiv. Allerdings sind im Verzeichnis **var/cache/production\_xxx/html/** immernoch Dateien und Ordner von vor 2 oder 3 Wochen zu finden. Deshalb meine Frage, was macht der Cronjob **Shopware\_CronJob\_ClearHttpCache** eigentlich bzw. wie kann ich im Dateisystem feststellen, ob dieser tatsächlich erfolgreich war?
Das bringt mich zu einem weiteren Verständnisproblem: Was sind die Unterschiede dieser Funktionen:
1. sw:cache:clear
2. clear\_cache.sh (in var/cache/)
3. Shopware\_CronJob\_ClearHttpCache
4. Cache löschen via Backend
---
### Author:  [@Moritz\_Naczenski](https://forum.shopware.com/u/Moritz_Naczenski)
#### Post date: [7. Oktober 2018 um 14:25 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/2 "2018-10-07T14:25:56Z")
clear\_cache.sh wirft den kompletten Ordner weg, nicht nur den HTTP-Cache und sollte nur als Rescue-Script genutzt werden. Das verursacht zusätzliche Datenbank-Last (bspw. für Models) die man nicht braucht. Im Backend wird auch bspw. der Konfigurationscache und der Template-Cache mit gelöscht und nicht nur der HTTP-Cache. Ist also nicht identisch mit dem Cronjob. Aus dem Kopf müsste sw:cache:clear identisch mit dem Shopcache leeren im Backend sein. Der HTTP-Cache Cronjob leert nur den HTTP-Cache und nichts anderes.
Feststellen kannst du eigentlich nur, ob der Ordner HTML im Cache-Verzeichnis nach dem Cronjob-Lauf kleiner ist.
---
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 14:29 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/3 "2018-10-07T14:29:30Z")
Vielen Dank für die schnelle Antwort. Diese Erklärung macht Sinn.
Hast du auch eine Idee wieso trotz täglichem positiven Ausführen von **Shopware\_CronJob\_ClearHttpCache ** im html Ordner noch jede Menge alte Dateien rumliegen? Diese müssten doch eigentlich gelöscht werden, richtig?
---
### Author:  [@Moritz\_Naczenski](https://forum.shopware.com/u/Moritz_Naczenski)
#### Post date: [7. Oktober 2018 um 14:32 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/4 "2018-10-07T14:32:16Z")
Alte Dateien weiß ich nicht. Soweit ich es in Erinnerung habe löscht der Cron nur Dateien, keine Ordner. Müsste ich aber auch erstmal testen. Glaube da gab es irgendeine Eigenheit.
---
### Author:  [@AndreHerking](https://forum.shopware.com/u/AndreHerking)
#### Post date: [7. Oktober 2018 um 16:45 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/5 "2018-10-07T16:45:34Z")
Ändert sich denn nach Ausführen des Cronjobs grundsätzlich etwas im Performance Modul (Größe des Reverse Proxys)? Falls nicht, kann hier auch das Access Log des Servers helfen, da Shopware bei Durchführung des Crons einen globalen BAN Request auslöst. Hier sollte man im Access Log schauen, welcher Status Code zurückgegeben wird (der korrekte Code müsste 200 sein).
LG Andre
---
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 17:27 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/6 "2018-10-07T17:27:59Z")
Okay…wir kommen der Sache näher…ich sehe den globalen BAN Request allerdings mit 301 statt 200…
**[07/Oct/2018:19:37:01 +0200] „BAN / HTTP/1.1“ 301 185 „-“ "Shopware/5.3.3"**
Ich nehme an, dass hier das Problem liegt?! An der Größe des Performance Moduls (Größe des Reverse Proxys) ändert sich nichts.
---
### Author:  [@AndreHerking](https://forum.shopware.com/u/AndreHerking)
#### Post date: [7. Oktober 2018 um 18:18 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/7 "2018-10-07T18:18:35Z")
Da würde ich mich mal an deinen Hoster wenden, irgendwie gibts hier lt. Status Code einen Redirect der das Ganze stört.
LG Andre
---
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 18:22 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/8 "2018-10-07T18:22:59Z")
Auf unserem Apache System bekommen wir einen **200er ** Status Code (allerdings wird der Request als GET angezeigt), aber gelöscht wird hier auch nichts:
**Apache: [13/Sep/2018:04:00:17 +0200] “GET / HTTP/1.1” 200 7227**
**Nginx: [07/Oct/2018:19:37:01 +0200] “BAN / HTTP/1.1” 301 185 “-” "Shopware/5.3.3"**
---
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 18:43 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/9 "2018-10-07T18:43:05Z")
Vermutung: Der Server sendet den BAN Request über seine externe IP-Adresse (steht auch im Access Log), also nicht über die 127.0.0.1 (deswegen blockiert Shopware diesen Request, sonst dürfte ja jeder den Cache löschen). Gibt es dafür eine Einstellung in Shopware oder muss das auch auf Seiten des Hosters geregelt werden?
---
### Author:  [@AndreHerking](https://forum.shopware.com/u/AndreHerking)
#### Post date: [7. Oktober 2018 um 19:02 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/10 "2018-10-07T19:02:57Z")
es gibt in den Cahe Performance Modul unter Einstellungen -\> HTTP Cache ein Feld zum Angeben eines alternativen Proxyservers,probier das mal.
---
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 19:20 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/11 "2018-10-07T19:20:18Z")
Leider ohne Erfolg. Steht bei dir in den Access Logs bei dem globalem BAN Request die externe IP oder 127.0.0.1?
---
### Author:  [@travisbotello](https://forum.shopware.com/u/travisbotello)
#### Post date: [7. Oktober 2018 um 20:11 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/12 "2018-10-07T20:11:50Z")
Okay…Problem gefunden. Es liegt an **NGINX** und betrifft wahrscheinlich viele Leute die **NGINX** und den **Shopware\_CronJob\_ClearHttpCache** benutzen. NGINX hat Probleme mit PUT, PATCH, DELETE, OPTION, TRACE und auch BAN Requests wenn diese an **/** gesendet werden. Wenn ich die Datei also **shopware.php** mit angebe, dann geht der Request durch und der Cache wird tatsächlich gelöscht.
➜ ~ curl -XBAN [https://meinshopware.com/](https://meinshopware.com/)
405 Not Allowed
➜ ~ curl -XBAN [https://meinshopware.com/shopware.php](https://meinshopware.com/shopware.php)
Der Redirect wurde übrigens dadurch verursacht, dass Shopware den **BAN Request ** an **http** statt **https** gesendet hat. Dadurch wurde der 301 Redirect an **https** gesendet. Aus dem **BAN** Request wurde so ein einfacher **GET** Request.
[07/Oct/2018:22:48:01 +0200] “BAN / HTTP/1.1” 301 185 “-” “Shopware/5.3.3”
[07/Oct/2018:22:48:01 +0200] “GET / HTTP/1.1” 200 7340 “-” “Shopware/5.3.3”
Also direkt zwei Probleme weshalb das nicht funktionieren kann. Wir verzichten nun auf den **Shopware\_CronJob\_ClearHttpCache** und nutzen stattdessen **sw:cache:clear** über einen eigenen Cronjob.
---
### Author:  [@wbob](https://forum.shopware.com/u/wbob)
#### Post date: [11. Februar 2019 um 10:54 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/13 "2019-02-11T10:54:00Z")
Ich habe upstream eine Lösung [vorgeschlagen](https://github.com/bcremer/shopware-with-nginx/pull/48). Darin wird der BAN Request innerhalb Nginx umgeschrieben auf die matching location die zu fastcgi weiterreicht. Wenn jemand Zeit findet die Lösung hier oder im github PR zu bestätigen, findet diese unter Umständen weitere Verbreitung.
---
### Author:  [@spirotech](https://forum.shopware.com/u/spirotech)
#### Post date: [11. Februar 2019 um 18:18 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/14 "2019-02-11T18:18:10Z")
Hallo wbob,
wo muss man die Zeilen einfügen. Nehme an in den Nginx Directiven, ist die Position wichtig ?
---
### Author:  [@miehnetto](https://forum.shopware.com/u/miehnetto)
#### Post date: [11. Februar 2019 um 18:22 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/15 "2019-02-11T18:22:36Z")
Was sagen denn die leute von Timmehosting dazu betrifft bestimmt auch die Shoppaket kunden?!
---
### Author:  [@spirotech](https://forum.shopware.com/u/spirotech)
#### Post date: [14. Februar 2019 um 19:17 UTC](https://forum.shopware.com/t/http-cache-loschen-ohne-auswirkungen/55605/16 "2019-02-14T19:17:23Z")
Interessiert das niemend von Shopware und TimmeHosting ??