Podlove-Statistik-Tool leitet auf https-URLs weiter

[henningkrause]

Als "Forschungspodcast" erforschen wir beim Resonator ja auch das Verhältnis von Podcastfeeds, dem neuen Tracking-Feature und SSL. Wir hatten ja im Ticket https://github.com/podlove/podlove-publisher/issues/619 besprochen, dass es gut wäre, wenn Holgers Downloadserver ein SSL-Zertifikat hätte. Das ist nun da. SSL Labs-Rating A+ (https://www.ssllabs.com/ssltest/analyze.html?d=files.wrint.de&latest), alles schick.

Nach dem Wiedereinschalten des Trackings, melden leider nicht nur wieder einige Android-Podcatcher Probleme, sondern auch Apple kann den Feed nicht lesen und daher waren wir mal kurz aus dem iTunes-Verzeichnigs geflogen und stehen da im Moment ohne jegliche Episode (https://itunes.apple.com/de/podcast/resonator/id641501347?mt=2). Ich verstehe, dass die alle selber schuld sind, ABER:

Was mir auffällt und was ich nicht verstehe: Wenn ich mir den http-Feed http://resonator-podcast.de/feed/m4a/ angucke, dann sind im Enclosure die Tracking-Weiterleitungen als https-URLs verlinkt. Zum Beispiel:

<enclosure url="https://resonator-podcast.de/podlove/file/1623/s/feed/c/m4a/RES054_Seltene_Erkrankungen.m4a" 
  length="22235504" 
  type="audio/mp4" 
  bitlove:guid="https://resonator-podcast.de/podlove/file/1623"/>

Dass so was in einen https-Feed wie https://resonator-podcast.de/feed/m4a/ dynamisch reingeschrieben wird, verstehe ich. Aber wieso wird bei http nicht auch das http für die Tracking-Weiterleitungs-URL übernommen? Ich könnte mir vorstellen, dass man so einige Probleme vermeiden könnte.

Im Wordpress selbst ist als Base-URL http://resonator-podcast.de/ ohne SSL eingetragen. Gibt es noch irgendwo ein Podlove-Base-URL, die ich setzen kann? Oder könnt ihr das so bauen, dass in http-Feeds http-Referenzen stehen und in https-Feeds https-Referenzen?

Danke!

[eteubert]

Was mir auffällt und was ich nicht verstehe: Wenn ich mir den http-Feed http://resonator-podcast.de/feed/m4a/ angucke, dann sind im Enclosure die Tracking-Weiterleitungen als https-URLs verlinkt.

Das ist mir auch noch unklar. Ich benutze zum Erzeugen des Links die WP-Funktion home_url, die sich selbst um die korrekte Auswahl des Schemes kümmert. D.h. WP ist der Meinung, das sei ein SSL-Request ... ?

Unabhängig davon habe ich aber etwas entdeckt, das auf jeden Fall falsch ist:

https-Download-Links redirecten auf http-locations. Da dürfen sich http-Bibliotheken gerne beschweren. Du solltest unter Podcast Settings > Media > Upload Location die https-Variante eintragen: https://files.wrint.de/.

[henningkrause]

Ahhh, danke!

Ich frage die Android-Nutzer mal, ob das deren Problem schon löst.

[henningkrause]

Wir haben heute eine neue Folge veröffentlicht: http://resonator-podcast.de/2015/res056-landschaftsoekologie/ - In der Episode stehen alle Häckchen auf grün. Der Webplayer spielt. Aber das Podlove-Dashboard meckert, siehe http://pastebin.com/YTUvU9Gw

Der "attempt repair"-Button hilft nicht. Scheinbar findet Podlove die Files nicht, obwohl sie auf Holgers Download-Server liegen. Keine Ahnung, ob das mit dem oben geschilderten https-Issue (und/oder den Analytics) zusammen hängt... Könnt ihr helfen? Danke!

[eteubert]

Der Publisher meint, https://files.wrint.de/res056-landschaftsoekologie.opus sei nicht erreichbar und so weit ich das sehe, existiert die Datei auch nicht.

[henningkrause]

Aber wie kommt der Publisher darauf, die Datei hieße so? Sie heißt https://files.wrint.de/RES056_Landschaftsoekologie.opus mit Unterstrich statt Strich, ist auch auf dem Server und in der Episode sind die Häckchen hinter den Dateien auch alle grün.

In der Fehlermeldung (http://pastebin.com/YTUvU9Gw) steht auch noch was von "Error: url must be a full URL".

[eteubert]

Unklar, muss ich mir nach meinem Urlaub ansehen, in reichlich einer Woche. Grüße aus Taiwan :)

[eteubert]

Hast du etwas geändert?

http://resonator-podcast.de/podlove/file/1726/s/download/c/select-show/RES056_Landschaftsoekologie.opus leitet nun korrekt weiter nach https://files.wrint.de/RES056_Landschaftsoekologie.opus?ptm_source=download&ptm_context=select-show&ptm_file=RES056_Landschaftsoekologie.opus

[henningkrause]

Ja, wir haben den Server der Wordpress-Webseite von einem virtuellen System auf eine dedizierte Maschine umgezogen. Seitdem sind viele Probleme, die einige Clients mit unseren https-Inhalten hatten, verschwunden. Ein Problem zuvor war wohl, dass zuvor irgendwelche Zwischenzertifikate verwendet wurden (Stichwort SNI) und jetzt auf einem gesonderten Server ist es besser.

Ansonsten habe ich an der Episode 56 nichts geändert. Nach dem Veröffentlichen der 57 sieht es ähnlich aus: Die Häckchen hinter den Files in der Episode sind grün, aber im Podlove-Dashboard scheitert die Validierung unserer Feeds (rotes X) und im Logging gibt es einige Fehlermeldungen: http://pastebin.com/HjNCLK7F

Was ich immer noch unverständlich finde, ist, dass der http-Feed durch die Analytics auf https-Zählweiterleitungen verlinkt. Was ja irgendwie unnötig ist.

[eteubert]

So weit ich das sehe, funktionieren alle Dateien in Episode 57. Und wenn ich mich nicht täusche, sind alle Anmerkungen des Validators Bugs des Validators >.<

Warning: Use of unknown namespace: http://bitlove.org, line 1 in Feed Resonator Warning: Use of unknown namespace: http://podlove.org/simple-chapters, line 1 in Feed Resonator Warning: Use of extension attribute on RSS 2.0 core element: (u'http://bitlove.org', u'guid'), line 37 in Feed Resonator

Er mag keine namespaces, die er nicht kennt. Das ist aber Unfug. Alles bestens.

Warning: Self reference doesn't match document location, line 10 in Feed Resonator

Okay, das ist eine Ungenauigkeit von uns, aber nicht tragisch. (passiert, wenn z.B. /feed/m4a statt /feed/m4a/ validiert wird)

Error: url must be a full URL, line 37 in Feed Resonator Error: href must be a full URL, line 486 in Feed Resonator

Diese beiden Zeilen führen zum roten X. Weil sie sich weigern, anzuerkennen, dass https existiert (https://github.com/rubys/feedvalidator/issues/16).

Vielleicht müssen wir den Validator schlicht entfernen, das wird zur Farce.

Was ich immer noch unverständlich finde, ist, dass der http-Feed durch die Analytics auf https-Zählweiterleitungen verlinkt. Was ja irgendwie unnötig ist.

Das verstehe ich nicht? Du meinst, dass Die Zugriffs-URLs https sind?

[henningkrause]

Ah, okay - danke für die Aufklärung. Dann mache ich mir keine Sorgen.

Was ich mit dem letzen Punkt meinte, war das, was ich schon weiter oben geschrieben hatte und was Du in https://github.com/podlove/podlove-publisher/issues/682#issuecomment-77096774 als ersten Punkt schonmal als Problem erkannt hattest: Im http-Feed http://resonator-podcast.de/feed/m4a/ stehen seit Aktivieren der Analytics im Enclosure-Tag URLs drin wie https://resonator-podcast.de/podlove/file/1751/s/feed/c/m4a/RES057_Von_der_Beobachtung_zur_Vorhersage.m4a - also https-URLs. Was ich beim https-Feed ja auch verstehen würde und gut so wäre. Aber beim http-Feed könnte doch ruhig http-Podlove-Analytics-Weiterleitungen referenziert werden. Es gibt so viele komische und unfähige Clients da draußen. Vielleicht könnte man damit schonmal ein paar Nervereien vermeiden. Auch wenn dann von dort aus nun natürlich auf https://files.wrint.de weitergeleitet wird, was ich ja jetzt entsprechend Deines Hinweises in https://github.com/podlove/podlove-publisher/issues/682#issuecomment-77096774 als Upload Location eingetragen habe.