HTTP Protokoll // Youtube



  • Hi,

    ich bin gerade dabei etwas mit Sockets rumzuspielen und wollte mir jetzt mal auf zB. Youtube die Daten für ein Video schicken lassen. Allerdings fehlt es hier etwas an know-how 😃

    TCP Verbindung über Port 80 und HTTP-Request (nur aus GET und HOST: bestehend) ist ja alles schnell aufgebaut, nur leider kriege ich da von Youtube immer nur eine weiterleitung auf andere Seiten. (?)
    Stellt sich die Frage was ich an Youtube schicken muss damit "es" mir ein Video schickt? Links zu guten (und etwas tiefergehenden) Erklärungen rund um das HTTP Protokoll würden mich ja vielleicht auch schon weiter bringen 😉

    Besten Dank schonmal im voraus für etwaige Antworten!





  • Hi,

    Danke für die schnelle Antwort aber Wikipedia kannte ich natürlich und die "Doku" hilft mir bei diesem Youtube spezifischen Problem erstmal auch nicht wirklich weiter 😉



  • Hier vielleicht noch einige Zusatzinfos:
    1. Ich habe der GET Anfrage jetzt den Link hinzugefügt der auch als src= benutzt wird beim einbinden der Videos via html. (Youtube bietet da ja was fertiges zu jedem Video an) Anfrage sieht jetzt also so aus:

    char request[] = 
      "GET /v/3GUHnoz2xFI?fs=1&amp HTTP/1.1\r\n"
      "Host: www.youtube.com\r\n\r\n";
    

    Die Antwort ist:

    HTTP/1.1 200 OK
    Date: Sat, 20 Nov 2010 13:37:14 GMT
    Server: Apache
    X-Content-Type-Options: nosniff
    Set-Cookie: VISITOR_INFO1_LIVE=4aerUVl26HA; path=/; domain=.youtube.com; expires=Mon, 18-Jul-2011 14:00:11 GMT
    Set-Cookie: VISITOR_INFO1_LIVE=4aerUVl26HA; path=/; domain=.youtube.com; expires=Mon, 18-Jul-2011 14:00:11 GMT
    Expires: Tue, 27 Apr 1971 19:44:06 EST
    Cache-Control: no-cache
    Content-Length: 1022
    Content-Type: application/x-shockwave-flash
    

    Danach kommt ein Datenblock der scheinbar nicht aus Text besteht, habe aber auch keine Idee welche Daten das sein könnten.. Auffällig ist dass am Anfang dieses Blocks IMMER (kann also kein Zufall sein) CWS steht. Google Suche nach "CWS" hat aber auch nicht wirklich was hergegeben..
    (Der Datenblock ist definitiv NICHT das Flash-Video dafür ist er viel zu klein und ausserdem müsste ein Flash-Video mit einem Flash-Header anfangen)

    Und danach (habe weiter nichts gesendet(!)) wird noch das geschickt:

    HTTP/1.0 400 Bad Request
    Content-Type: text/html; charset=UTF-8
    Content-Length: 1350
    Date: Sat, 20 Nov 2010 14:00:11 GMT
    Server: GFE/2.0
    

    Der Nachrichten-body besteht dann aus einer gewöhnlchen google-Fehlermeldung.

    Auffällig ist hier dass im header auf einmal HTTP/1.0 steht obwohl die Anfrage ja auf 1.1 war. Mache ich eine Anfrage mit HTTP/1.0 kommt dieser letzte Textblock nicht mit.

    Ich denke also dass ich Youtube irgendwie so antworten muss dass es mir die Daten für das angeforderte Video schickt. "Content-Type: application/x-shockwave-flash" kriege ich ja schon. Die Frage ist halt nur was ich jetzt antworten muss.

    PS: Das Problem hat sich irgendwie mehr in Richtung "Rund um die Programmierung" entwickelt, eventuell verschieben 😉



  • Wenn ich einen Server erstelle der auf Port 80 lauscht und genau das oben beschriebende Packet sendet (ohne Fehlerblock) und dann mit Firefox localhost ansurfe passiert genau das erwartete, das Youtube Video wird angezeigt. (Man kann es auch abspielen)
    Da im HTTP header nicht genug Informationen für dieses Verhalten vorhanden sind, wird "CWS" wohl so eine art magic number sein, und der nicht-ASCII (Rohdaten) Block wird dem Flashplayer wohl die benötigten Daten liefern.

    Jetzt fragt sich nur noch wie man diesen Datenblock richtig interpretieren muss.. falls jemand den Sourcecode für den Flashplayer hat.. :D:D



  • HalloWelt schrieb:

    Wenn ich einen Server erstelle der auf Port 80 lauscht und genau das oben beschriebende Packet sendet (ohne Fehlerblock) und dann mit Firefox localhost ansurfe passiert genau das erwartete, das Youtube Video wird angezeigt. (Man kann es auch abspielen)
    Da im HTTP header nicht genug Informationen für dieses Verhalten vorhanden sind, wird "CWS" wohl so eine art magic number sein, und der nicht-ASCII (Rohdaten) Block wird dem Flashplayer wohl die benötigten Daten liefern.

    HalloWelt schrieb:

    (...)

    (...)
    Content-Type: application/x-shockwave-flash
    

    Denk mal drüber nach...



  • hustbaer schrieb:

    HalloWelt schrieb:

    Wenn ich einen Server erstelle der auf Port 80 lauscht und genau das oben beschriebende Packet sendet (ohne Fehlerblock) und dann mit Firefox localhost ansurfe passiert genau das erwartete, das Youtube Video wird angezeigt. (Man kann es auch abspielen)
    Da im HTTP header nicht genug Informationen für dieses Verhalten vorhanden sind, wird "CWS" wohl so eine art magic number sein, und der nicht-ASCII (Rohdaten) Block wird dem Flashplayer wohl die benötigten Daten liefern.

    HalloWelt schrieb:

    (...)

    (...)
    Content-Type: application/x-shockwave-flash
    

    Denk mal drüber nach...

    Nunja falls du das meinst, was ich denke was du meinst (oO^^) dann kann ich nur sagen dass der Daten Block definitiv zu klein für das Video ist. Er ist genau 1024 Bytes groß und so gut ist die Komprimierung dann doch noch nicht 😉



  • Natürlich ist der Datenblock nicht das Video, hab ich auch nie behauptet.



  • Dann steh ich gerade auf dem Schlauch^^
    Vielleicht hilfst du mir ja das Wasser wieder zum fließen zu bringen? 😃





  • Der Datenblock wird wohl der Flash-Player sein bzw. ein Stub der den Player nachlädt.
    Das Video selbst wird wohl von einer anderen URL gestreamt.



  • hustbaer schrieb:

    Der Datenblock wird wohl der Flash-Player sein bzw. ein Stub der den Player nachlädt.
    Das Video selbst wird wohl von einer anderen URL gestreamt.

    Soweit war ich auch schon, nur sind die Daten leider nicht in Klartext vorhanden und jetzt stellt sich natürlich die Frage wie komme ich da drann? 😉

    SG1 schrieb:

    http://www.digitalpreservation.gov/formats/fdd/fdd000130.shtml#sign (bzw http://webcache.googleusercontent.com/search?q=cache:CE3jLFw-bGkJ:www.digitalpreservation.gov/formats/fdd/fdd000130.shtml+magic+bytes+cws&cd=6&hl=en&ct=clnk&client=ubuntu#sign im google cache) lässt mich vermuten, dass du das mal durch die zlib jagen solltest.

    Guter Tipp Danke 😉
    Leider gibt er mir bei uncompress() Z_DATA_ERROR zurück. ("Z_DATA_ERROR if the input data was corrupted or incomplete").

    Habe noch nie mit dieser lib gearbeitet bin mir also etwas unsicher wie ich das angehen soll. Schön wäre wenn es vielleicht sowas wie einen online-decodierer geben würde zum testen..
    Denn was soll da raus kommen? Klartext? Oder wieder nur interne Datenstrukturen mit denen erstmal nur der Flash-Player selbst was anfangen kann?



  • HalloWelt schrieb:

    hustbaer schrieb:

    Der Datenblock wird wohl der Flash-Player sein bzw. ein Stub der den Player nachlädt.
    Das Video selbst wird wohl von einer anderen URL gestreamt.

    Soweit war ich auch schon, nur sind die Daten leider nicht in Klartext vorhanden und jetzt stellt sich natürlich die Frage wie komme ich da drann? 😉

    Wie kommst du auf die Idee dass Flash-Anwendungen Klartext wären?



  • Ich glaube wir reden etwas aneinander vorbei^^
    Ich habe doch geschrieben dass es eben KEIN Klartext ist 😉
    Allerdings ist es so gut wie klar dass in dem Datenblock zummindest die "Streaming-IP" stehen muss. Die Frage ist halt wo das steht bzw. wie man es vorher vielleicht sogar noch dekodieren muss..



  • Und du bist dir sicher, dass die IP im KLARTEXT in den Daten steht? Sie muss ja nicht zwangsläufig als ASCII-Code drinstehen. Binärkodierung wäre auch möglich.



  • Guck mal ob du irgendwo Infos zum Flash-File-Format bekommst.
    Also ob die Daten komprimiert sind, wenn ja wie, ob da vorne noch eine Header o.ä. dran ist uswusf.



  • O.o schrieb:

    Und du bist dir sicher, dass die IP im KLARTEXT in den Daten steht? Sie muss ja nicht zwangsläufig als ASCII-Code drinstehen. Binärkodierung wäre auch möglich.

    Ich glaube Du hast das ganze immer noch nicht so ganz verstanden.. sry 🙄

    hustbaer schrieb:

    Guck mal ob du irgendwo Infos zum Flash-File-Format bekommst.
    Also ob die Daten komprimiert sind, wenn ja wie, ob da vorne noch eine Header o.ä. dran ist uswusf.

    Leider nicht wirklich, zummindest nicht über Google..
    Wenn ich mir die Cache-Files die Firefox von Youtube Videos so macht angucke sieht man wohl eine art Header..

    "FLV" sind immer die ersten 3 Bytes, dann kommt irgendwann "onMetaData" "duration" "starttime" "totalduration" "videodatarate" usw.

    Etwas weiter unten gibt es sogar noch einen
    "httphostheader" mit nem Wert wie zB. "v21.lscache7.c.youtube.com".
    Dieser Wert kann allerdings nicht wirklich reichen, da ja irgendwo noch die Video ID her kommen muss.

    Nunja ich komme hier momentan leider auch nicht wirklich weiter.. wenn ich noch etwas neues finde schreib ichs hier rein - für gute Infos/Tipps wäre ich natürlich auch dankbar, aber eine konkrete Frage habe ich gerade leider nicht mehr 😞

    Wer das Problem nachvollziehen möchte kann gerne einfach eine TCP Verbindung über Port 80 auf www.youtube.com aufbauen - ich nutze momentan folgende HTTP Anfrage:

    char request[] = 
        "GET /v/VIDEOID<-- HTTP/1.0\r\n"
        "Host: www.youtube.com\r\n"
        "\r\n";
    

    Daten dann einfach mit fwrite oder sowas binär schreiben und sich die Datei dann mit nem HexEditor ansehen 😉



  • HalloWelt schrieb:

    SG1 schrieb:

    http://www.digitalpreservation.gov/formats/fdd/fdd000130.shtml#sign (bzw http://webcache.googleusercontent.com/search?q=cache:CE3jLFw-bGkJ:www.digitalpreservation.gov/formats/fdd/fdd000130.shtml+magic+bytes+cws&cd=6&hl=en&ct=clnk&client=ubuntu#sign im google cache) lässt mich vermuten, dass du das mal durch die zlib jagen solltest.

    Guter Tipp Danke 😉
    Leider gibt er mir bei uncompress() Z_DATA_ERROR zurück. ("Z_DATA_ERROR if the input data was corrupted or incomplete").

    Die Header besteht anscheinend aus 8 Byte, d.h. diese 8 Byte musst du wegschneiden/überspringen bevor du die Daten an ZLIB übergibst.

    ps: das 4. Byte ist irgendeine Versionsnummer, und die nächsten 4 Byte sind die Länge des Files in irgend einer Form. Vermutlich inklusive Header und bei CWS die Länge des komprimierten Files (kannst du aber leicht checken was nun zutrifft).




Log in to reply