Antennapod lädt Feed nicht

[deka]

Ich erhielt kürzlich eine Nachricht eines Nutzers, der den Podcastfeed der Seite mit Antennapod abonniert hat. Die Software zeigt zwar, die einzelnen Beiträge an. Es wird jedoch keines der Dateien in den Feeds heruntergeladen.

Ich habe die Gegenprobe mit einem anderen Feed gemacht. Dort klappt es. Ich nutze unter Android die App Podcast Addict. Dort wird der MP3-Feed des obigen Datenkanal ebenfalls heruntergeladen.

Der Feedvalidator hält den Feed für gültig.

Habt ihr eine Idee, woran das liegen kann bzw. wo ich anfangen kann, zu suchen?

[onli]

Im https://datenkanal.org/rss.php?version= ... format=mp3 steht neben den Dateien HTML Document. Man kommt zwar über den Link zur richtigen Datei, und der Mime-Type scheint auch zu stimmen, aber man wird von http:// zu https:// weitergeleitet. Ich vermute, dass diese Weiterleitung entweder s9y als Feed-Ersteller, wenn da irgendwo mime-types gesetzt werden, oder den Feedreader (evtl. kommt das HTML von meinem als Feedbetrachter genutzten Firefox).

Ich würde versuchen, die Dateien direkt als https:// einzubinden, oder für Dateien und feed SSL zu deaktivieren. Manche Feedreader kommen damitimmer noch nicht richtig zurecht.

[deka]

Ich hatte die Audiodateien ursprünglich direkt als HTTPS eingebunden. Dies sorgte jedoch dafür, dass der Feed gar nicht mehr validierte. Offensichtlich müssen die Dateien als HTTP-Links im Dokument stehen.

Ich werde mal schauen, wie ich die Dateien mit dem korrekten Mime-Type ausliefern kann.

[onli]

Im Zweifel per .htaccess die Audio-Dateien auch per http:// ausliefern lassen (https:// muss ja nicht gesperrt werden). Sollte ich zufällig wirklich das Problem erwischt haben, dann sollte das helfen.

[deka]

Also das Problem scheint folgendes zu sein:

Die Dateien kommen im Feed über einen HTTP-Link vor. In meiner Webserver-Konfig leite ich alle HTTP-Anfragen nach HTTPS weiter (301). Das heißt, das Easy-Podcasting-Plugin ruft die Datei auf und sieht eine Weiterleitung mit Content-Type text/html. Das schreibt es in den Feed rein, also text/html und die Größe der Antwort (eine Hand voll Byte).

Antennapod sieht Content-Type text/html und denkt sich: »Hmm, HTML kann ich nicht abspielen, also ignoriere ich das mal.« Andere Player folgen dem Link und laden die Datei herunter.

Jetzt könnte ich in den Feed überall HTTPS-Links reintun. Dann stünden korrekte Content-Types etc. drin. Aber der Feed validiert wegen HTTPS nicht mehr.

Ich kann die Dateien per HTTP ausliefern, was ich nicht möchte. Ich möchte gern alles per HTTPS ausliefern.

Das Easy-Podcasting-Plugin könnte die Umleitung erkennen, schauen, was dahinter verborgen ist und das Ergebnis als Content-Type, Größe etc. anzeigen. Die URL müsste aber die Gleiche bleiben. Das fühlt sich aus meiner Sicht aber auch unsauber an.

Daher finde ich gerade keine so wirklich passende Lösung. Habt ihr eine Idee?

[onli]

Wenn du auf https bestehst, würde ich alles auf https setzen. Ignorier den Validator, https nicht zu erlauben ist nicht gut. Vll wird das gemacht, um kompatibler mit mehr Podcast-Clients zu sein. Aber wenn du mit ein paar Clients testen kannst und zufrieden mitder Kompatibilität bist ist der Valdiator zweitranging.

Wenn mit https tatsächlich zu viele Clients aussteigen, dann würde ich vorschlagen im Easy-Podcasting-Plugin der Weiterleitung zu folgen, also den finalen mime-type und die richtige Größe zu setzen. Ich sollte dir zeigen können, wie dafür der Code angepasst werden muss, und könnte einen entsprechenden Patch nach Absprache mit Garvin wahrscheinlich auch nach Spartacus schieben.

[garvinhicking]

Wie genau machst Du die Weiterleitung? Ein text/html sollte nur kommen wenn die Weiterleitung nicht direkt per HTTP läuft, sondern inline via meta oder javascript, was dann nicht gut wäre...

[deka]

Die Weiterleitung läuft per HTTP:

Code: Select all

 ~ $ curl -I http://datenkanal.org
HTTP/1.1 301 Moved Permanently
…
Content-Type: text/html
…
Location: https://datenkanal.org/
Strict-Transport-Security: max-age=15768000; includeSubDomains
…

Das Ganze läuft direkt im nginx:

Code: Select all

location / {
    return 301 https://datenkanal.org$request_uri;
}

[garvinhicking]

Hi,

ok, dann ist das eigentlich richtig. Kannst Du dir mal die serendipity_event_podcast.php zur Brust nehmen und dort wo:

Code: Select all

$http = new HTTP_Request($url);

steht folgendes draus machen:

Code: Select all

$http = new HTTP_Request($url, array('allowRedirects' => true));

GGf hilft das schon. Für Serendipity 2.1 und das aktuelle Plugin nutzen wir HTTP_Request2, und da wäre das defaultmäßig auch aktiviert...

[deka]

Ich habe die Änderung mal eingebaut. Es hat aber am Feed nach meiner Meinung nichts geändert. Ich setze im Blog auf S9Y 2.1-a3 und die aktuellste Version des Plugins,