proxy (squid) lokal soll lokal mp4 und jpg einer URL cachen

[egerlach]

Hallo,
hat mir jemand einen Tipp für einen proxy, der die mp4 und jpg einer URL (https) cachen soll? squid soll alles können, ja, hat mir jemand für diesen speziellen Fall ein tutorial? - Gibts einen einfacheren proxy für meinen Fall? - Warum? - Ich habe keine Flatrate, nur Mobilfunkanbindungs ins Web und will beim Entwickeln einer Webseite das ständige erneute Laden der mp4 und jpg sparen, die ändern sich nicht.
Gruß
Eckard

[GregorS]

hat mir jemand einen Tipp ...

Tipp nicht, aber eine Frage: Wieso richtest Du Dir nicht eine lokale Virtuelle Maschine ein, die den Webserver nachstellt, für den Du programmierst? Damit bräuchtest Du überhaupt keine Verbindung „nach Draußen“.

[egerlach]

Gute Idee ... dann gelegentlich ein rsync, die Maria-DB export -> per skript User/PWs/Pfade austauschen -> import im web, das im Rahmen einer kurzzeitig gebuchten flatrate. Flatrate für paar Stunden mache ich sowieso alle paar Tage. Das bekomme ich hin, derartiges schon häufig gemacht. Dann noch einige spezielle Rechte setzen bei all-inkl.com. Das per Skript. So meinst Du das, ja? - Machbar! Überlege ich mir ....

Ob sich der Aufwand lohnt? - wordpress braucht zum entwickeln einer Seite keine Web-Verbindung, nur beim Speichern und Anfangs einmalig Laden der IDE ca. 5MB. Da ist nichts gewonnen. Nur die zahlreichen selbst lautlos startenden Videos und jpg's machen Netzlast, alles andere ist in Sachen Internet-Kosten über Mobilfunk (hier in Bolivien für deutsche Verhältnisse günstig!) vernachlässigbar. Ich glaube das lohnt nicht, ich werde meine Arbeiten an der Webseite zusammenfassen und konzentriert in der wenige-Stunden-Flatrate erledigen ... Oder es kommt mit jemamd und sagt das mit squid das ist einfach ... mach so und so und schon gehts.

[GregorS]

... So meinst Du das, ja? ...

Keine Ahnung, was Deine Aufgabe konkret erfordert. Ich habe für viele Web-Programmierereien halt das lokal „nachgestellt“, was ich benötigt habe bzw. was halt für den jeweiligen Kunden als Vorgabe existierte.

[uname]

Vielleicht kurz zurück zu Squid falls sonst noch jemand auf die "dämliche" Idee kommt:
Da es sich um HTTPS-Verbindungen handelt, wirst du Squid-in-the-middle SSL Bump benötigen. Das wiederum funktioniert nur, wenn du deinen Anwendern in deren Browsern ein spezielles TLS/SSL-Zertifikat unterschiebst. Vergiss also Squid oder andere HTTP(S)-Proxy-Lösungen.

Du kannst aber die Dateien regelmäßig z. B. per wget downloaden und z. B. über einen normalen lokalen Webserver bereitstellen. Für eine "Web-GUI" kannst du mit etwas mehr Aufwand uf einem lokalen Webserver mit PHP (aber ohne MariaDB) auch Tiny File Manager mit "Upload / Upload from URL" verwenden. Meine etwas abgedrehte und mittlerweile etwas veraltete Anleitung zum Tiny File Manager findest du hier.

Heutzutage cacht eigentlich niemand mehr im lokalen Netzwerk. Es werden im Internet CDNs und lokal nur der Client genutzt. Wie viele Hundert GB sind es denn?

Ich habe keine Flatrate, nur Mobilfunkanbindungs ins Web und will beim Entwickeln einer Webseite das ständige erneute Laden der mp4 und jpg sparen, die ändern sich nicht

.
Schau mal in den Browser DEV Tools (Taste F12), ob die Dateien wirklich neu geladen werden. Auch kannst du mal im Cache deines Browsers schauen.

[wanne]

Hier etwas ausführlicher:
Zuerst mal zum lösbaren Problem https: Die Idee von Verschlüsslung ist eben, dass das niemand mitlesen kann welche URL du gerade aufrufst. Das kann man auf 2 Arten lösen.
a) Den Browser dazu zu bringen kaputte Verschlüsslung zu nutzen.
b) Den Cache im Browser machen.
Da a) für viele nicht so erstrebenswert ist, ist b) der üblicherweise erstrebenswertere Weg. Deswegen hat das jeder Browser schon eingebaut. In about:cache kannst du dir anzeigen lassen, wie viel der Browser gerade cached. – Und feststellen, dass das marginal wenig ist.

Der Grund dafür ist wie heutige Webseiten funktionieren, und dass der Satz "das ständige erneute Laden der mp4 und jpg" auf heutigen Webseiten Unsinn ist.

• Auch wenn deine URL auf jpg endet. JPEGs sind riesig für ihre Qualität. 90er Jahre Technologie halt. Real kommt da kein jpg zurück sondern je nach dem, was dein Browser kann ein deutlich kleineres AVIF, JPEG XR oder webp mit gleicher Qualität. Nur wenn du die URL mit wget aufrufst bekommst du ein jpg. Wenn dein Proxy jetzt das webp für den Chrome deinem IE der nur JPEG XR versteht vorsetzt kommt Mist raus. Genau so umgekehrt. Deswegen cachen proxies sowas gar nicht. Ein weiterer Grund, warum du den Cache im Browser haben willst. Früher gab es dafür den eTag-Hader um zu sagen welche Variante für wen geliefert werden soll. Heute sendet das praktisch keine Webseite mehr.
• Klassisches html5-Video mit einfacher src-Adresse ist leider tot. Alle nutzen es mit MSE oder HLS. Beide ermöglichen Methoden das Video während dem Abspielen zu verändern. Genutzt wird das um je nach Internetgeschwindigkeit die Qualität und Größe anzupassen. Wind das Internet langsamer gibt es mehr Artefakte und ein kleineres Video. => Jeder Aufruf der Website ein anderes Video. Prinzipiell könnte dir das Wurst sein. Aber ob du gerade ein völlig anderes Video guckst oder nur das gleiche Video in anderer Qualität ist für Browser oder Proxy nicht trivial und im Allgemeinen maximal nach dem Download herauszufinden. Bei youtube kann man auf den v= Parameter achten. Aber das ist halt speziell für youtube, dass das immer das gleiche Video ist wenn es den gleichen v= Parameter hat. Und Details wie Sprache Auflösung und zu welcher Sekunde du gesprungen bist verrät dir das immer noch nicht.
• Auch wenn das etwas mehr verschwindet: PHP Entwickler lieben es unterschiedliche Inhalte über die selbe URL auszulieferen. Caching macht da natürlich Unsinn. Passend gibt es Header die Proxy/Browser anweisen das Caching zu unterlassen. Da das fehlen von passenden Headern immer wieder zu Problemen geführt hat gibt es viele Admins, die passende Header einfach immer senden. Auch PHP tut das per default. Auch wenn jedes mal der gleiche Inhalt kommt. Jetzt gibt es viele Heuristiken die solche Fehlerhaft gesendeten Header erkennen versuchen. Was regelmäßig zu ärger führt. Wenn du das vorherige gecachte Captcha sendest...
• Zu Letzt ist der absolute Killer Tracking: Während viele Webseiten Bilder noch davon ausschließen wollen die meisten Webseiten wissen von wo du was aufgerufen hast. Deswegen generieren sie immer neue URLs für die gleichen Inhalte. So können sie sehen ob du das Ergebnis aus den Suchergebnissen oder die Werbung in deiner E-Mail angeklickt hast. Dass 2 mal die gleiche URL aufgerufen wird, kommt deswegen absichtlich so gut wie nicht mehr vor.

All das macht Caching für Inhalte vom Browser defakto unmöglich. Es gibt deswegen von Vodafone oder Opera Proxies die alles neu Komprimieren. Das führt dann aber auch passend zu weniger Qualität.
Prinzipiell gibt es im HTTP-Standard den Content-Digest-Header der das Problem lösen könnte, indem nicht mehr abhängig von der URL sondern von diesem Header gecached wird. Genutzt wird das aber nur von spezialisierten Tools die große Daten per HTTP übertragen. Nicht von Browser/Webseiten. Fürs einfache Surfen ist Internet jetzt einfach schnell/billig genug, dass sich keiner mehr die Mühe machen will, da Sparmaßnahmen zu implementieren.

[egerlach]

1000 dank für die ausführlichen Stellungnahmen. Ja, ich habe noch nicht gemessen, ob ein Browser wirklich pro Tag alles erneut herunterlädt und eventuell kann ich da sogar einstellen, dass der Cache für 1 Monat bestehen bleibt, werde ich alles mal untersuchen.
Es geht um 500MB Videos und 100MB Fotos. Ich hatte bisher immer das Gefühl, es würde jedesmal alles wieder heruntergeladen. Mein Gefühl hat mich da evtl. getäuscht.

@gerade getestet: FF lädt jedesmal alle Videos und Bild erneut aus dem Internet! Ich habe 10 min gewartet und dann die gleiche Webseite neu geladen und das gleiche Video darauf erneut abspielen lassen, zwischendurch nichts gemacht: gemäß der Tx und Rx von ifconfig (USB-stick):

Code: Alles auswählen

wwx0c5b8f279a64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.40.119.246  netmask 255.255.255.252  broadcast 10.40.119.247
        ether 0c:5b:8f:27:9a:64  txqueuelen 1000  (Ethernet)
        RX packets 525214  bytes 700183645 (700.1 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 228603  bytes 19564039 (19.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

habe ich mit ein paar Videos (je ca. 30MB) auf paar Seiten ein RX von 400MB produziert (300MB von einem Update meines ubuntu). Der FF cached also gar nicht! So hatte ich es auch noch in Erinnerung. Der Cache scheint standardmäßig für mp4 (und jpg ?) abgeschaltet. Den werde ich mal unter die Lupe nehmen.

@neuer Test gerade eben: Standard video-Player von wordpress im Einsatz. Video ist NICHT auf autoplay. Seite neu geladen. Video NICHT angeklickt, es wurde NICHT abgespielt. Der FF hat das 27MB-Video komplett neu aus dem Web heruntergeladen. Innerhalb der letzten Stunde wurde das Video X-Male neu aus dem Internet heruntergeladen. Habe gerade eine 4-Std-Flatrate gebucht, macht mir eigentlich nichts, vielleicht sperrt mich der Provider hier in Bolivien demnächst für Flatrates, weil ich zuviel Daten innerhalb der 4 Stunden herunterlade . Also brauche ich eine Lösung. Ich muss den Cache des FF mal untersuchen ...

gemacht:

Code: Alles auswählen

about:cache  
[...]
   disk
Maximum storage size: 	1048576 KiB
[...]

1GB cache. Das sollte reichen.

Settings des FF nach "cache" gesucht:
"Your stored cookies, site data, and cache are currently using 1.3 GB of disk space. Learn more..."
ok.

klick auf "Manage Data":
bei meiner URL nachgesehen, auf der ich arbeite: Mem 329kB für data und cookies ???
Meine URL wird überhaupt nicht ge'cached!?!?!
Mir schwant es: mein wordpress-CMS hat dem Browser FF irgendwie mitteilt, dass NICHTS gecached werden soll. damit ich Änderungen z.B. an einer css-Konfiguration sofort im Browser-Fenster sehe und nicht den cache von vor Stunden/Tagen/Wochen. Das könnte ich abstellen, dann sehe ich die Änderungen aber auch erst nach Tagen/Wochen/... , richtig?
Also nutzt mir der Browser-Cache nichts! Ich muss ja die Änderungen sehen! Es hilft nur die MB-"Klopse", die Videos, bei Bearbeitung der Webseite auf dem Webserver umzubenennen per Skript, z.B. ein "_" an das mp4 anfügen, dann werden die Videos nicht mehr gefunden und werden nicht mehr abgespielt. Wenn ich dann fertig bin mit meinen Arbeiten, benennt ein zweites Skript die wieder zurück. In der Zeit können Besucher der webseite auch keine Videos sehen, bekommen "Fehler...." angezeigt ...
Oder: das Skript verlinkt die mp4 ohne "_" (und jpg) alle auf ein ultra-kurzes Video mit Standbild "Wartung...". Diese Lösung gefällt mir sehr gut

[GregorS]

... Mir schwant es: mein wordpress-CMS hat dem Browser FF irgendwie mitteilt, dass NICHTS gecached werden soll. damit ich Änderungen z.B. an einer css-Konfiguration sofort im Browser-Fenster sehe und nicht den cache von vor Stunden/Tagen/Wochen. Das könnte ich abstellen, dann sehe ich die Änderungen aber auch erst nach Tagen/Wochen/... , richtig? ...

Nicht unbedingt. Ich weiß nicht, wie's beim aktuellen FF ist, aber man konnte mal mit irgendeiner Tastenkombination ein Neuladen unter Umgehung des Caches erzwingen (äh ... Strg-F5 ...?)

[egerlach]

Ich will doch gerade cachen, wordpress umgeht das caching von sich aus schon, da brauche ich nicht erst irgendeine Taste zu drücken.

Ich versuche gerade über wordpress forum heraus zu bekommen, wie ich das unterdrückte caching bei wordpress nach Anmeldung abstellen kann.

[uname]

Vielleicht ein anderes CMS. Oder mach ein Bild vom Film, stell das Bild in Wordpress ein und verlinke dort das Video. Dann muss man klicken für das Video. Video nur im Download-Bereich von Wordpress oder außerhalb von Wordpress.

[wanne]

Der Cache scheint standardmäßig für mp4 (und jpg ?) abgeschaltet.

Klassisches html5-Video mit einfacher src-Adresse ist leider tot. Alle nutzen es mit MSE oder HLS. Beide ermöglichen Methoden das Video während dem Abspielen zu verändern. Genutzt wird das um je nach Internetgeschwindigkeit die Qualität und Größe anzupassen. Wind das Internet langsamer gibt es mehr Artefakte und ein kleineres Video. => Jeder Aufruf der Website ein anderes Video. Prinzipiell könnte dir das Wurst sein. Aber ob du gerade ein völlig anderes Video guckst oder nur das gleiche Video in anderer Qualität ist für Browser oder Proxy nicht trivial und im Allgemeinen maximal nach dem Download herauszufinden. Bei youtube kann man auf den v= Parameter achten. Aber das ist halt speziell für youtube, dass das immer das gleiche Video ist wenn es den gleichen v= Parameter hat. Und Details wie Sprache Auflösung und zu welcher Sekunde du gesprungen bist verrät dir das immer noch nicht.

Mir schwant es: mein wordpress-CMS hat dem Browser FF irgendwie mitteilt, dass NICHTS gecached werden soll. damit ich Änderungen z.B. an einer css-Konfiguration sofort im Browser-Fenster sehe und nicht den cache von vor Stunden/Tagen/Wochen.

Auch wenn das etwas mehr verschwindet: PHP Entwickler lieben es unterschiedliche Inhalte über die selbe URL auszulieferen. Caching macht da natürlich Unsinn. Passend gibt es Header die Proxy/Browser anweisen das Caching zu unterlassen. Da das fehlen von passenden Headern immer wieder zu Problemen geführt hat gibt es viele Admins, die passende Header einfach immer senden. Auch PHP tut das per default. Auch wenn jedes mal der gleiche Inhalt kommt. Jetzt gibt es viele Heuristiken die solche Fehlerhaft gesendeten Header erkennen versuchen. Was regelmäßig zu ärger führt. Wenn du das vorherige gecachte Captcha sendest...

Das könnte ich abstellen, dann sehe ich die Änderungen aber auch erst nach Tagen/Wochen/... , richtig?

Nein. Da HTTP immer ein Änderungsdatum mitliefert und der FF weiß, wann er das Bild runter geladen hat würden Änderungen sofort sichtbar werden, da der FF ja kontrollieren kann ob das vor oder nach der letzten Änderung war. Das ist eine Nummer schlimmer: Wordpress ändert auch bei so Sachen wie Logins, neuste Nachrichten oder Sortierungen die URL nicht. DAS tut dann erst nach Wochen. Keine Chance da irgend was mit dem PHP-Kram zu erreichen. Die meisten Lösen das Problem, indem sie die "großen Klopse" auf einen 2. Server ohne PHP zu packen. (Auch wenn man das theoretisch auf einem Server vereinen könnte.) dann brauchst du aber auch ein passendes Wordpress plugin, dass die Bilder wirklich vom externen Server lädt. Wenn ich mich recht entsinne, verlinkt Wordpress nur manchmal und lädt externe Bilder auch manchmal schlicht runter und liefert sie dann selbst aus statt sie zu verlinken. Das Zauberwort dazu ist Image-CDN. Leider verkaufen dir die meisten immer Plugin+Server.
Aber wenn du die Bilder mit "From URL" auf einen anderen Server verlinkst statt sie in die Galerie hochzuladen funktioniert Caching zumindest manchmal.

[uname]

Ich habe noch mal geschaut. Ich verwende WordPress nicht. Aber du kannst mal Caching for WordPress durchlesen. Vor allen das Caching auf dem Client könnte interessant sein. Das kann aber zu Problemen führen. Vielleicht musst du mal das Neuladen dann erzwingen mit "Strg Shift r" oder "Strg F5".

Trotzdem würde ich große Dateien wohl eher außerhalb von WordPress aufbewahren. So kannst du z. B. Nextcloud oder einfach einen normalen Webserver verwenden. In WordPress kannst du ja darauf verlinken. Gerne verlinke auch auf das direkt sichtbare Verzeichnis (.htaccess: Options +Indexes), um zu sehen von wann die Datei wirklich ist. Auch sind Web File Manager wie Tiny File Manager nützlich. Besser als WordPress sind sie allemal.

[egerlach]

doch noch nicht vollständig gelöst!!! trotzdem schon mal 1000 Dank an alle Mithelfer hier!!

Damit gehts, ab in die .htaccess, es lag tatsächlich am Hoster meiner sites (all-inkl.com), dass überhaupt gar nie etwas gecached wird / wurde:

Code: Alles auswählen

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
#ExpiresByType text/html "access plus 1 month 15 days 2 hours"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
</IfModule>

Zahlreiche Hinweise auf diese Technik gibt es. Fast alle verschweigen aber, dass ein

Code: Alles auswählen

<IfModule mod_expires.c>
ExpiresActive On
[...]
</IfModule>

mit dabei sein muss. Selbst die Apache-Website weiss davon scheinbar nichts Habe es nur zufällig von einem Beitrag auf stackoverflow.com mitbekommen, dass um die ExpiresByType ... noch etwas drumherum gehört.

Der obige code hat an einem Tag funktioniert, auch Videos wurden ge'cashed. Jetzt, 2 Tage später, werden videos nicht mehr gecashed. bei den jpg's funktioniert es, da werden auch die jpg-Bilder von vor 2 Tagen gefunden. Videos werden jetzt immer und immer wieder aus dem Internet gesaugt. Warum ??
Stopp: genauer: Videos werden 2 Male komplett heruntergeladen, danach sind sie erst gecashed! Und auch offenbar nur für einen Tag gültigl Uff!! Sehr merkwürdig. Hat hier jemand eine Idee wie auch Videos entsprechend der Aweisung in der .htaccess "für einen Monat" gecashed werden?

Mein hoster all-inkl.com installiert wordpress auf Wunsch per klick. Dabei wird würd wordpress auch in die .htaccess was eingetragen, nicht aber das caching.

Übrigens: was FF in about:preferences zu "manage data" -> mein URL eingeben ausgibt, ist nach wie vor 329kb, das stimmt überhaupt nicht, jetzt sind ca. 200MB an Videos und 10MB an jpg im cache, das wird nicht angezeigt. Habe jetzt mehrfach mit mehreren Videos und Seiten mit vielen jpg's geprüft , dass gecached wird, ifconfig zeigt die MB durch das interface ja an.