Statische Dateien auf anderen Host auslagern

[deka]

Für meinen Podcast habe ich im Verzeichnis uploads/podcast die Audiodateien liegen. Mittlerweile ist das auf eine recht stattliche Größe angewachsen und wird irgendwann den verfügbaren Platz des Hosts sprengen. Daher würde ich diese Dateien gern auf einen anderen Host auslagern und die dann beispielsweise unter https://cdn.example.org anbieten.

Meine Frage ist nun, wie ich das am besten anstellen kann. Habt ihr gute Hinweise?

Die Frage hat noch folgenden Hintergrund:

Ein naheliegender Weg ist eine Umleitung von https://example.org/uploads/podcast auf https://cdn.example.org. Das wird aber bei der Erzeugung des Feeds Probleme bereiten. Denn das Plugin ruft die URL auf und schreibt dann als Content-Type text/html mit einer Größe von ein Handvoll Byte rein. Damit stolpern diverse Podcatcher und laden die Dateien nicht mehr runter.

Ein anderer Weg wäre, die URLs in den alten Beiträgen direkt zu ändern. Das führt wiederum dazu, dass der Beitrag bei vielen Podcatchern als neu angezeigt wird und die dann alle Folgen nochmal runterladen. Abgesehen vom Zusatztraffic finde ich als Nutzer sowas immer recht nervig.

Daher bin ich auf der Suche nach guten Ideen, um das Problem zu lösen.

[onli]

Ich schaue mir gerade den Code des Podcast-Plugins an. Da gibt es zumindest Utnerstützung für auswärts liegende Dateien, https://github.com/s9y/additional_plugi ... t.php#L953, Und er würde versuchen, den Mime-Type aus dem Header auszulesen. Und serendipity_request_url folgt sogar redirects.

Mir ist nicht ganz klar, wie s9y das bemerken würde. Muss die Datei dann woanders liegen, und in die ML nur als Link hinzufügt werden? Aber grundsätzlich könnte das schon funktionieren.

Aber ich würde das einfach nur für neue Episoden ändern, und bei den alten alles so lassen wie es ist.

[deka]

Soweit ich das richtig verstehe, würde der Code für die Anfrage unten text/html als Content-Type nutzen. Wenn aber das finale Ziel audio/FOO ist, wäre das falsch.

~> curl -I http://google.com
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.de/?gfe_rd=cr&ei=m2in ... 8QfrmLSABQ
Content-Length: 258
Date: Fri, 17 Feb 2017 21:18:19 GMT

Was meinst du mit ML?

[deka]

Aber ich würde das einfach nur für neue Episoden ändern, und bei den alten alles so lassen wie es ist.

Ich muss das nochmal probieren. Aber im Falle eines Redirects befürchte ich genau das beschriebene Verhalten. Also in dem Falle sollten die alten enclosure-Tags chflas sein.

[onli]

Soweit ich das richtig verstehe, würde der Code für die Anfrage unten text/html als Content-Type nutzen.

Klar, abe du gehst du ja auch zu Google. Mach das gleiche mal mit der Audiodatei.

Was meinst du mit ML?

Media Library, die Mediendatenbank.

[deka]

Soweit ich das richtig verstehe, würde der Code für die Anfrage unten text/html als Content-Type nutzen.

Klar, abe du gehst du ja auch zu Google. Mach das gleiche mal mit der Audiodatei.

Das Problem ist hier das Zusammenspiel aus Podcatcher und Feedreader. Im Feed steht bei einer Umleitung sowas wie:

Code: Select all

<enclosure url="http://example.org/foo.mp3" type="text/html" length='1234' />

Jetzt gibt es Feedreader, die das sehen und sich "denken", text/html kann ich nicht abspielen. Fertig. Das heißt, die versuchen nie der URL zu folgen.

Für mich würde das bedeuten, dass ich im Fall eines Umzugs den Feed "manuell" (vermutlich per Skript) korrigieren muss.

[onli]

Wenn der im richtigen Codepfad landet gibt es aber eigentlich keinen Grund, warum da text/html stehen sollte. Er versucht, den richtigen mime-type vom Content-Type-Header des Servers auszulesen. Wenn der Server den ordentlich setzt, dann wäre das ein Bug im Plugin.