Seit ein paar Tagen (ich würde sagen, kurz nach dem Update auf Discourse 2.5 Beta 5 – und es setzt sich in Beta 6 fort – aber das könnte auch ein Zufall sein) funktioniert die Einbettung von YouTube-Videos nur noch intermittierend. Nach einigen Stunden, in denen es nicht funktionierte, hat es einfach wieder normal funktioniert.
Seit gestern funktioniert es überhaupt nicht mehr.
Ich sehe in den Forum-Protokollen keinen spezifischen verdächtigen Fehler.
Könnte es ein Timeout-Problem sein? Gibt es eine Möglichkeit, dies gezielt zu untersuchen?
Bei der Untersuchung des Verkehrs, der durch die Anforderung einer Neubearbeitung eines Beitrags mit einem YouTube-Link entsteht, habe ich etwas Seltsames festgestellt.
Die Anfrage schlägt mit dem Fehler 404 fehl.
Noch ein paar zusätzliche Details.
Ich verwende Discourse 2.5.0.beta6, aktualisiert auf Commit 2d880b42a3 (kurz vor dem Absenden dieses Beitrags neu erstellt).
Beim Erstellen eines neuen Beitrags mit einem YouTube-Link erscheint in der Google Chrome-Konsole kurz vor dem 404-Fehler für die GET-Anfrage an Onebox ein zusätzlicher Fehler, der sich auf einen Fehler bei der Registrierung des Service Workers bezieht.
Ich möchte darauf hinweisen, dass alle Oneboxes funktionieren, außer YouTube.
Der Browser kann Ihnen nicht den tatsächlichen Grund für das Scheitern einer Onebox mitteilen. Sie müssen versuchen, eine ähnliche Anfrage von Ihrem Server aus zu stellen.
Wenn ich den einfachen GET-Aufruf (mit Header und anderen erwarteten Parametern) an /onebox?url=… wiederhole, erhalte ich einfach den HTML-Fehler 404.
Wenn ich die Anfrage, die Onebox stellt, auf dem Server wiederhole, indem ich sie aus dem Ruby-Code von youtube_onebox.rb kopiere, also curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik' für eines der nicht eingebetteten Videos, scheint es perfekt zu funktionieren.
Der Aufruf gibt tatsächlich folgendes zurück: {"author_name":"AstronautiCAST","version":"1.0","height":270,"author_url":"https:\/\/www.youtube.com\/user\/AstronautiCAST","provider_name":"YouTube","provider_url":"https:\/\/www.youtube.com\/","thumbnail_height":360,"width":480,"html":"\u003ciframe width=\"480\" height=\"270\" src=\"https:\/\/www.youtube.com\/embed\/Xl-PTTeRsik?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen\u003e\u003c\/iframe\u003e","type":"video","thumbnail_width":480,"title":"Loading cargo into HTV-9 Konutori","thumbnail_url":"https:\/\/i.ytimg.com\/vi\/Xl-PTTeRsik\/hqdefault.jpg"}root@fait-2020:/var/discourse#
was alles enthält, was Onebox zum Einbetten benötigt.
@Falco, es tut mir wirklich leid, dich zu stören, aber das Fehlen von YouTube-Onebox-Links beeinträchtigt die Benutzererfahrung in unserem Forum erheblich.
Gestern habe ich mehrere Versuche unternommen, etwa den Quellcode zu lesen (um zu verstehen, in welchem Stadium und unter welchen Bedingungen eine 404-Antwort von Onebox ausgelöst wird), bis hin zum Klonen des aktuellen Produktionsforums auf einen neuen, separaten Digital Ocean Droplet.
Das Lesen des Codes hat nicht wirklich geholfen, hauptsächlich wegen meines fehlenden fundierten Wissens über die Plattform.
Eine Frage bleibt dabei offen: Wird der Onebox-Prozess irgendwo protokolliert? Es wäre so hilfreich, den Fehler zu verstehen, der Onebox dazu bringt, aufzugeben und eine 404 zurückzugeben.
Der geklonte Droplet war ein Versuch, zu prüfen, ob die IP-Adresse des Produktions-Servers von YouTube blockiert wurde und gleichzeitig, ob es etwas mit unserem verwendeten Domainnamen zu tun hat.
Nun, obwohl sich sowohl die IP-Adresse als auch der Domainname unterschieden, funktionierte das YouTube-Oneboxing nicht.
Ich hoffe wirklich, dass mir jemand zumindest einen Weg aufzeigen kann, nachzuvollziehen, was Onebox genau tut.
Ich habe die Grundursache: YouTube hat unsere IP gesperrt, aber es ist unklar warum, da wir zu dem Zeitpunkt, als dies geschah, keine massiven Neuberechnungen oder Ähnliches durchführten.
Frage an @Falco oder @codinghorror: Hat die Installation von 2.5.0beta 5 oder 6 eine Neuberechnung ausgelöst, die das Anfrage-Limit überschritten hätte?
Danke an alle für die Antworten.
Mir ist jedoch weiterhin unklar, warum ich, wenn ich die Anfrage des Onebox-Engines nachmache (oder zumindest erwarte ich das – ist das @Falco?), eine JSON-Antwort mit einer korrekten Antwort erhalte und nicht einen 429-Fehler.
Gibt es eine weitere Anfrage von Onebox, die vor der Ausführung der Anfrage gemäß meinem Screenshot einen 429-Fehler zurückgibt, nämlich curl 'https://www.youtube.com/oembed?format=json&url=https://www.youtube.com/watch?v=Xl-PTTeRsik'?
Es versteht sich von selbst, dass diese Anfragen vom selben Server aus gestellt wurden, auf dem Discourse läuft (also dieselbe ausgehende IP-Adresse).
Ein einziger curl-Befehl wird wahrscheinlich kein Rate Limit auslösen.
Versuchen Sie es mit mehreren Befehlen in schneller Folge? Führen Sie sie in einem wiederholenden Bash-Skript aus? (Aber nicht zu oft, sonst könnten Sie gesperrt werden.)
Eine interessante Erkenntnis nach einem Wochenende der Fehlersuche.
Das könnte etwas sein, das du dir vielleicht ansehen möchtest, @Falco oder @codinghorror?
Derzeit sehe ich beim Lesen des Quellcodes von youtube_onebox.rb, dass drei URL-Formate unterstützt werden, aus denen die Video-ID extrahiert wird:
http://youtu.be/<videoid>
https://www.youtube.com/embed/<videoid>
https://www.youtube.com/watch?v=<videoid>
Jeder Versuch, Videos im Format 1 und 3 zu einboxen, schlägt fehl; Onebox gibt einen 404-Fehler zurück (was meiner Meinung nach daran liegt, dass unsere IP gesperrt wurde).
Wenn ich jedoch Links im Format 2 einbinde, funktioniert es!
Ich frage mich, ob und wie dies mit dem Zusammenhang zusammenhängen könnte, der in diesem Beitrag erklärt wird.
Ein gewisses Verständnis (und Logging) der inneren Funktionsweise von Onebox (also welche genauen Aufrufe an YouTube getätigt werden) wäre extrem hilfreich…
Ich bin zurück, um diesen Thread abzuschließen.
Gestern hat YouTube unsere Sperre aufgehoben und wir sind wieder im Geschäft.
Es gibt ein paar Punkte, die meiner Meinung nach trotzdem interessant zu verstehen wären:
Könnte Onebox im Falle eines fehlgeschlagenen Onebox-Vorgangs die Details protokollieren? Das wäre sehr hilfreich, um genau zu verstehen, warum Onebox fehlschlägt.
Da das einzige notwendige Element für das Oneboxen von YouTube-Videos die Video-ID ist, wäre es dann nicht eine gute Idee, Daten von allen drei URL-Typen abzurufen, bevor ein 404 zurückgegeben wird (wie oben erwähnt, funktionierte die /embed/-URL irgendwie nie, selbst während der Sperre).
Danke an alle, die auf meine panischen Fragen geantwortet haben!
GENAU DAS!!! (ist eine sehr gute Idee, die ich bereits erwähnt habe)
Ich vermute, ein Teil der Herausforderung besteht darin, dass Onebox nicht weiß, wenn das Ziel eine Seite ohne Open-Graph-Tags zurückgibt, ob dies auf eine Weiterleitung zurückzuführen ist. Dies könnte jedoch protokolliert werden („ONEBOX: keine OG-Tags gefunden?"), und alle Fehler, die zu leeren Onebox-Ergebnissen führen, sollten auf jeden Fall protokolliert werden.
tl;dr Ich möchte hinzufügen, dass wir hier offenbar dasselbe Problem erleben. Wenn es aufgrund einer kürzlichen Änderung ein Rate-Limit-Problem gibt, werden meiner Meinung nach andere Benutzer dies während der Migration, beim Neuberechnen (Re-baking) von Beiträgen oder einfach wegen eines sehr aktiven Forums ebenfalls erleben. Die Tatsache, dass Oneboxen scheinbar fehlerstill ausfällt, bedeutet, dass diese Probleme erst sichtbar werden, wenn Benutzer sich beschweren, dass YouTube-Oneboxes fehlen.
Hintergrund
Wir nutzen Version 2.6.0.beta 1.
Benutzer erhielten Meldungen über nicht sichere Inhalte. Bei der Untersuchung stellte sich heraus, dass Chrome sich über Bilder beschwerte, die von HTTP-Seiten verlinkt waren. Daher habe ich Discourse so konfiguriert, dass es alle Bilder/Medien herunterlädt und über HTTPS bereitstellt.
Nachdem ich diese Einstellung geändert hatte, musste ich historische Beiträge neu berechnen (Re-bake). Seit diesem Re-bake sind viele YouTube-Videos, die zuvor als Onebox dargestellt wurden, wieder in die verlinkte URL zurückverwandelt worden.
Wir haben einen Thread mit 10.000 Beiträgen, der ausschließlich aus YouTube-Video-Antworten besteht, und alle Beiträge sind URLs und keine Oneboxes.
Während des Re-bakes wurden alle gestapelten Aufgaben organisch verarbeitet; es handelt sich also nicht um Aufgaben, die in einer Warteschlange gelöschter Jobs stecken.
Ich habe nicht dieselben Fehlermeldungen gesehen wie @marcozambi, aber ich bin überzeugt, dass wir ebenfalls ein Rate-Limit auslösen.
Was habe ich versucht?
Als Unterstützung für die Rate-Limit-Theorie: Ein kleiner Code-Abschnitt, den ich zum Neuberechnen von Beiträgen geschrieben habe, funktionierte für die ersten 80+ YouTube-Videos in einem Thread und scheiterte dann bei der Umwandlung der restlichen Videos.
Zu diesem Zeitpunkt führte selbst das Bearbeiten eines Beitrags, das Vornehmen einer kleinen Änderung und das erneute Speichern nicht dazu, dass die URL als Onebox „aufgeklappt
Ich bin nicht überzeugt, dass das /embed/-Format für Links hier ein Allheilmittel ist.
Meiner Einschätzung nach scheint es sich um einen Pfad mit separaten Rate Limits zu handeln, sodass, wenn der Pfad https://youtu.be/<video-id> ein Limit erreicht, ein anderer Pfad mit einem separaten Limit für die Route https://youtube.com/embed/<video-id> existiert.
Ein Beleg dafür, dass beide Routen limitiert sind, stammt aus einem Hilfsprogramm, das ich geschrieben habe, um das Format der YouTube-Einbettungen in einem riesigen Thread mit 10.000 Beiträgen zu ändern, der zu 99 % aus YouTube-Videoreplies bestand.
Zu diesem Zeitpunkt scheiterte Onebox bereits daran, die im Format https://youtu.be/<video-id> formatierten Links zu erweitern.
Mein Hilfsprogramm, das die YouTube-Videourl in das Format https://youtube.com/embed/<video-id> umwandelte, wurde auf die ersten 3.000 Beiträge im Thread angewendet.
Es funktionierte gut für die ersten 1.108 Beiträge, und während es das Format für die nächsten ca. 1.900 Beiträge änderte, wurden diese von Onebox nicht erweitert.
Während dieser Zeit wurden viele Jobs generiert (mein Code nutzte post.revise), und alle wurden ohne Fehler oder Wiederholungsversuche verarbeitet.
Anekdotisch fiel mir auf, dass die Jobverarbeitung an einer bestimmten Stelle dramatisch beschleunigt zu sein schien. Ich vermute, das könnte daran gelegen haben, dass der Onebox-Code schnell eine Art Fehler von YouTube erhielt – ich habe es jedoch nicht gemessen, und es könnten auch andere Faktoren gewesen sein.
Ich würde gerne bereitwillig detailliertere Beweise liefern, bin mir aber nicht sicher, was ich tun kann, ohne das Onebox-Gem zu instrumentieren.
Ich bin ein Hacker und kein Ruby-Experte, aber ich würde mich gerne an einigen hochrangigen Anweisungen versuchen.
Das Ausführen kurzer, sich wiederholender curl-Skripts von der Befehlszeile des Servers mit demselben User-Agent kann Ihnen helfen, ein Rate-Limit-Problem zu isolieren.
Ich stimme zu, dass der Workaround wahrscheinlich nur funktioniert, weil es sich um eine separate Zählung handelt.
Hier sind weitere Ergebnisse. Beachten Sie, dass der folgende Beitrag viele Annahmen enthält – basierend auf mangelndem fundiertem Wissen.
Ich werde auf diesen Beitrag mit meiner Einschätzung folgen, was hier vor sich geht und was geschehen sollte.
Danke für die Antwort, Robert.
Beachten Sie, dass das Oneboxing von Videos über die Route /watch (und das ist immer noch so!) fehlgeschlagen ist, als ich es versucht habe, sodass ich keine Schleife benötigte, um einen Fehler zu erzwingen.
Eine Annahme, die ich getroffen habe, ist, dass der user-agent, den Onebox verwendet, Discourse Forum Onebox v2.6.0.beta1 lautet, basierend auf diesem Code…
Ich habe ein zufälliges Video ausgewählt und versucht, mit curl die Header auszulesen.
Ich habe dies innerhalb des Docker-Containers auf meiner Live-Site durchgeführt, was folgende Antwort ergab.
Ich wurde also mit einer 303-Antwort an die URL im location-Header weitergeleitet, die https://www.youtube.com/watch?v=s0ONj4TG0UA&app=desktop lautete.
Dies hatte lediglich den Effekt, &app=desktop an die URL anzuhängen.
Ergebnis des zweiten curl an die umgeleitete URL – immer noch auf der Route /watch?
Ich erhalte also einen 429-Statuscode „zu viele Anfragen“, aber ohne einen retry-after-Header gesendet zu bekommen – sofortiges Aufhören ohne Verhandlung.
Wie auch immer, wenn Onebox dies sieht, ignoriert es die Antwort, oder zumindest weiß ich nicht, wo ich danach suchen soll, falls sie protokolliert wird.
Obwohl dies vielleicht für einen einzelnen 429-Fall legitim sein könnte, können viele 429-Antworten in sehr kurzer Zeit nicht ignoriert werden.
Ergebnis des dritten curl – diesmal mit der Route /embed/
Zur Vollständigkeit habe ich sofort versucht, dasselbe Video abzurufen, diesmal jedoch über die Route /embed/.
Das lazy-yt-Plugin scheint URLs im /watch-Format umzuschreiben
Ich bin mir nicht sicher, ob dies überhaupt von Bedeutung ist, aber… ist das eingebettete Plugin lazy-yt standardmäßig aktiviert? Ich habe es in meiner Entwicklungsumgebung bemerkt.
Es scheint die to_html-Methode des YouTube Oneboxers zu patchen (monkey patch).
Ich weiß nicht, ob dies von Bedeutung ist, aber die ursprüngliche to_html-Methode des Oneboxers gibt das /embed/-URL-Format zurück…
Während das lazy-yt-Plugin das /watch?v=-URL-Format verwendet.
Gibt es noch etwas anderes, das ich tun kann, um zu zeigen, dass es ein Problem gibt, das Aufmerksamkeit erfordert? Im nächsten Beitrag werde ich erklären, was ich als die Ursache des Problems betrachte.
