Podlove Subscribe Button liefert HTTP- statt HTTPS-Link an Player-Apps aus


#1

Moin zusammen.

Ich habe gerade meinen Podcast (schleifenquadrat.fm) nicht nur wiederbelebt, sondern auch auf HTTPS umgestellt. Das funktioniert soweit auch gut (siehe Screenshots) auf der Website und sogar in iTunes.

Wenn ich den Podlove-Subscribe-Button nutzen möchte, scheitere ich jedoch. Wähle ich “Andere App” wird korrekt der HTTPS-Link zum Feed angezeigt. An Apps wie zum Beispiel Castro (siehe Screenshot) wird aber ein HTTP-Link weitergerreicht. Bei der Weitergabe an Overcast fehlt das Protokoll anscheinen komplett, denn dort taucht die Adresse nur ab dem “www” auf.
In Castro funktioniert das Abonnieren trotzdem, in Overcast zum Beispiel aber nicht.

Ich habe da jetzt schon (hoffentlich) alle Einstellungen und Optionen durchgespielt und keine Idee mehr.
Kann jemand helfen?5621


#2

Da das Thema heute auch auf Twitter an mich herangetragen wurde, beantworte ich das auch mal hier.

Das Problem ist nicht wirklich beim Button zu suchen. Um auf dem Gerät die richtige App zu triggern, wird das Schema der URL genutzt.

Um z.B. die App von Apple auf dem iPhone aufzurufen, wird aus

http://fasel.bla
podcast://fasel.bla

Durch das Schema “podcast://”, das die App in iOS registriert hat, weiß das Gerät, welche App aufgerufen werden soll.

Und genau hier steckt dann das Problem. Durch das ersetzen des Schemas ist für die App hinterher nicht mehr identifizerbar, ob es sich um http oder https handelt. Als das alles erdacht wurde, war https kein wirkliches Thema und deshalb wird an der Stelle immer http unterstellt.

Dafür gäbe es nun zwei Lösungen: Die Apps reagieren und registrieren zwei Schemata (ob das geht, weiß ich nicht, dafür steck ich nicht genug in der Programmierung unter iOS, Android + Co). Eine könnte dann podcast:// heißen, eine ander podcasts:// - eine Unterscheidung wäre wieder möglich.

Eine andere Lösung liegt beim Podcast bzw. dem Hoster: Eine permanente Weiterleitung von http:// auf https://

Beide Lösungen finde ich irgendwie nicht richtig prickelnd. Über zwei Schemata bin ich zwar erstmal raus aus der Nummer, aber erstens ist es unwahrscheinlich, dass alle Apps hier anständig reagieren und das zeitnah erledigen und nunja… wenn irgendwann ein drittes Schema auftaucht (was weiß ich, was dieses Web für uns noch so bereit hält) oder jemand auf die Idee käme, ganz andere Protokolle heranzuziehen (ftp://? ;-)), dann sieht’s düster aus. So richtig sauber ist das alles nicht.

Lösung zwei birgt das Problem, dass man vom Hoster abhängig ist und nicht alle können das am Ende umsetzen.

Dennoch würde ich, weil kurzfristig umsetzbar, aktuell immer Lösung zwei vorziehen. Am Ende bleibt das der realistischste Weg. Eine kleine Konfiguration am Webserver und gut.

Hab ich was vergessen? Bestimmt :slight_smile:


#3

Danke für die Erklärung.
Aktuell gehe ich auch den zweiten Weg. Der funktioniert recht simpel. Ich würde mich entsprechend auch dieser Empfehlung anschliessen.

Am Rande, falls jemand das gleiche Problem haben sollte wie ich neulich:
Der Podlove Repair Button im WP-Backend hat jeweils die generelle Weiterleitung aus meiner .htaccess entfernt. Seit ich die auf read-only gesetzt habe, funktioniert der beschriebene Weg gut.


#4

Falls die Apps das eh selbst beheben müssen können sie ja auch erst mal versuchen über HTTPS einen validen Feed zu bekommen (sauberste Lösung).

Dann ist man auch auf der sicheren Seite wenn die Plattformen endlich mal beschließen dass Apps gefälligst gar keine unverschlüsselten Verbindungen aufzubauen haben.