ptk+2008-01-27 20:24:58--

Die GET-Zeile ist kein Header, sondern die Requestzeile selbst. Evtl. bekommst du noch mehr Information, wenn du die Methode as_string verwendest oder einen Dump mit Data::Dumper machst.
Host kannst du im Zweifelsfall selbst konstruieren: der Wert ist immer der Hostname der URL, ggfs. mit Port.

Tja, irgendwie echt hinderlich daß das Auslesen derartige Schwierigkeiten macht...
Dieses Script ist Teil eines Suchmaschinen-Projektes und in den Headern sind Informationen, die so ohne weiteres nicht zu extrahieren sind. So ist in das besagte Redtube-Beispiel nicht das Ziel aber exemplarisch insofern als z.B. Content-Length Angaben in den Headern vergraben und auch redirects auf andere Objekte wie Videos enthalten sind. Diese Informationen sollen irgendwie berücksichtigt werden aber ausser der Methode, direkt an der Karte abzugreifen sehe ich da auch nach werweißwielangem Suchen immer noch keine Möglichkeit.
Beispiel für die Weiterleitung auf das Video ist z.B.

http://dl.redtube.com/_videos_t4vn23s9jc5498tgj49i...

GET /_videos_t4vn23s9jc5498tgj49icfj4678/0000007/-------.flv?start=0 HTTP/1.1
Host: dl.redtube.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: pp=1; __utma=217855893.1664202611.1201469264.1201469264.1201469264.1; __utmb=217855893; __utmc=217855893; __utmz=217855893.1201469264.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)

HTTP/1.x 200 OK
Content-Type: application/octet-stream
Etag: "104921028"
Accept-Ranges: bytes
Last-Modified: Fri, 12 Oct 2007 12:12:14 GMT
Content-Length: 5470576
Date: Sun, 27 Jan 2008 21:29:23 GMT
Server: RT-209

Wie gesagt: rankommen kann man an die Daten mit dem Netzwerk-Karten Workaround aber das ist nicht für alle Server anwendbar.
Dann will ich mal weitersuchen...

Was meinst du mit Weiterleitung? Ein Redirect? Der Server antwortet aber mit 200...

Irgendwie verstehe ich nicht, wo das Problem liegt...

ptk+2008-01-28 00:14:13--

Was meinst du mit Weiterleitung? Ein Redirect? Der Server antwortet aber mit 200...

Irgendwie verstehe ich nicht, wo das Problem liegt...

Der Ablauf ist so, daß Du die URL aufrufst, die entsprechenden Grafiken, JS usw. für den Seitenaufbau geladen werden und zum Abschluß automatisch das Video startet, das in dem o.g. Header aufgeführt ist.
Das Video startet also ohne speziellen Aufruf durch den User. Die URL des Videos ist nur aus den Headern zu rekonstruieren, nicht aus dem HTML-Text.
Das ist mittlerweile häufig angewandte Technik und daher muß für SuMa-Spider entsprechend die Software angepaßt werden.
Für Youtube (vergleichbare Technik) gibt es mittlerweile sogar bei CPAN entsprechende Releases WebService::YouTube::Video , für andere Angebote muß man das eben durchprogrammieren und zwar egal ob Video oder anderes Medium.
Ich muß also nicht nur an den Body-Text ran sondern an alles, was vom Server ankommt um alle Medien zu berücksichtigen.
Momentan versuche ich es mal mit WWW::Mechanize, wenn jemand andere Tips hat: wäre nett...

So, ich habe jetzt mal den Rat befolgt und einen Browser nachgebaut auf Basis von LWP::UserAgent.
Danach habe ich den Zugriff auf eine Seite mit TamperData für Firefox protokolliert und sowohl die gesendeten Header wie die Response-Header analysiert.
LWP::UserAgent wurde dann so angepaßt, daß die Header in LWP identisch sind mit den gesendeten Headern aus Firefox.
Die Resultate sind auch so weit identisch was Response-Header und Content-Ausgabe betrifft, dann jedoch beginnt der Unterschied genau da, wo im Firefox ein Verweis auf ein Video empfangen wird, bei LWP::UserAgent jedoch nicht.
Es stellt sich jetzt die Frage, woher dieser Verweis auf das abzuspielende Video kommt, wenn doch alle Header identisch sind? (An JavaScript kann es nicht liegen, denn die Video-URL kommt in FireFox auch rein wenn JS deaktiviert wurde)
Im Content ist auch kein Verweis vorhanden, irgendwo im Datenstron muß aber die URL des Videos sein, nur: wo???

Niemand eine Idee?

An welcher Stelle bekommt den Firefox den Verweis auf das Video?

Unterschiedlich.
Manche Anbieter schicken es am Ende, manche in der Mitte, manche im letzten Drittel; es gibt da keine einheitliche Linie. Bei Clipfish z.B. ist es mittendrin:
----------------------------------------------------------
http://pg1.clipfish.de/media/7b/852f58fd225197331c...

GET /media/7b/852f58fd225197331caa12709d0c48e57b.flv HTTP/1.1
Host: pg1.clipfish.de
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: newsRead=2008-02-04+16%3A47%3A23; ip_bt=36; wlrcmd=; __utma=68674883.1870368408.1202147103.1202147103.1202147103.1; __utmb=68674883; __utmc=68674883; __utmz=68674883.1202147103.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none)

HTTP/1.x 200 OK
Date: Mon, 04 Feb 2008 17:45:18 GMT
Server: Apache
Last-Modified: Thu, 31 Jan 2008 15:44:18 GMT
Etag: "2023180e-e78c1-87d75880"
Accept-Ranges: bytes
Content-Length: 948417
Expires: Wed, 06 Feb 2008 16:51:15 GMT
Age: 4583
Keep-Alive: timeout=2, max=128
Connection: Keep-Alive
Content-Type: text/plain
----------------------------------------------------------
Ich habe Dir das Clipfish-Protokoll aus LiveHTTPheaders mal als PM geschickt damit Du einen Eindruck bekommst.