nicht angemeldet
MIME multipart
Hallo!
Ich habe folgendes Problem und bisher keine funktionierende Lösung gefunden: Auf einer per Perl-Skript generierten Seite finden sich Thumbnails von Bildern, die auf detaillierte Dateiinformationen weiterverlinken. Damit sich die Bilder (bzw. generell beliebige Dateien, aber für Bilder halte ich eine Vorschau einfach praktisch) nicht jeder einfach per URL ansehen kann, ist die Quelle der Thumbnails ein Perl-Skript, dem eine ID des Bildes übergeben wird. Das Skript prüft erstmal, ob der (sich vorher authentifizierte) Benutzer auch die Rechte besitzt, sich diese Bilder anzusehen, bevor er das Bild ausgibt.
Soweit funktioniert alles wunderbar. Der Knackpunkt bei der Geschichte ist aber, dass bei jedem Thumb ein neuer Perl-Prozess gestartet werden muss und viele Aufgaben, wie das Überprüfen der Rechte, unnötig häufig stattfinden und das Laden dementsprechend langsam vorangeht.
Auf der Suche nach einer passenden Lösung bin ich auf den MIME-Typ multipart gestoßen und habe versucht, dies zu implementieren. Der Testcode schaut wie folgt aus:
#-------------------------------------------------------------
print "Content-type: multipart/mixed; boundary="newpart"\n\n";
print "--newpart\n";
print "Content-type: text/html\n\n";
print "hallo, dies ist ein kleiner test\n\n";
print "--newpart\n";
print "Content-type: image/jpeg\n\n";
open(FILE,"</data/temp/testbild.jpg") || die "fehler";
binmode(FILE);
binmode(STDOUT);
while(read(FILE, $buffer, 1024)) {
print $buffer;
}
close(FILE);
#-------------------------------------------------------------
Leider scheint kein Browser diesen MIME-Typus zu unterstützen =(
Gibt es denn eine andere, vielleicht elegantere, Lösung, dies umzusetzen, ohne den vorher angesprochenen Mehraufwand leisten zu müssen? Ich würde außerdem gerne bei Standard-Perl bleiben und nicht auf Dinge wie mod_perl oder fast-cgi ausweichen müssen.
Vielen Dank schonmal im Voraus,
Max
-
Soweit funktioniert alles wunderbar. Der Knackpunkt bei der Geschichte ist aber, dass bei jedem Thumb ein neuer Perl-Prozess gestartet werden muss und viele Aufgaben, wie das Überprüfen der Rechte, unnötig häufig stattfinden und das Laden dementsprechend langsam vorangeht.
so wie du es beschreibst, sollte das Skript im Bruchteil einer Sekunde fertig sein, falls nicht ist da irgendwo der wurm drin.
Auf der Suche nach einer passenden Lösung bin ich auf den MIME-Typ multipart gestoßen und habe versucht, dies zu implementieren. Der Testcode schaut wie folgt aus:
Ich weiß nicht wo du gesuchst hast, aber ich kenne dieses Format nur bei e-mails. Vor allem was willst du damit erreichen? Dein Skript macht doch dann das gleiche wie vorher.
Struppi.
-
hi,
Ich habe folgendes Problem und bisher keine funktionierende Lösung gefunden: Auf einer per Perl-Skript generierten Seite finden sich Thumbnails von Bildern, die auf detaillierte Dateiinformationen weiterverlinken. Damit sich die Bilder (bzw. generell beliebige Dateien, aber für Bilder halte ich eine Vorschau einfach praktisch) nicht jeder einfach per URL ansehen kann, ist die Quelle der Thumbnails ein Perl-Skript, dem eine ID des Bildes übergeben wird. Das Skript prüft erstmal, ob der (sich vorher authentifizierte) Benutzer auch die Rechte besitzt, sich diese Bilder anzusehen, bevor er das Bild ausgibt.
Soweit funktioniert alles wunderbar. Der Knackpunkt bei der Geschichte ist aber, dass bei jedem Thumb ein neuer Perl-Prozess gestartet werden muss und viele Aufgaben, wie das Überprüfen der Rechte, unnötig häufig stattfinden und das Laden dementsprechend langsam vorangeht.
An dieser Stelle solltest du ansetzten: Wenn der User sich bereits vorher authentifiziert hat, bekommt er nur die Thumbs gezeigt die er auch aufrufen darf, dann entfällte eine zweite Prüfung.
Auf der Suche nach einer passenden Lösung bin ich auf den MIME-Typ multipart gestoßen und habe versucht, dies zu implementieren. Der Testcode schaut wie folgt aus:
#-------------------------------------------------------------
print "Content-type: multipart/mixed; boundary="newpart"\n\n";http://perlbase.xwolf.de/cgi-bin/perlbase.cgi?dis.10.1
... so sieht der header aus.Viele Grüße, Rolf
--
SELFforum - Das Tor zur Welt!
Theoretiker: Wie kommt das Kupfer in die Leitung?
Praktiker: Wie kommt der Strom in die Leitung?-
Soweit funktioniert alles wunderbar. Der Knackpunkt bei der Geschichte ist aber, dass bei jedem Thumb ein neuer Perl-Prozess gestartet werden muss und viele Aufgaben, wie das Überprüfen der Rechte, unnötig häufig stattfinden und das Laden dementsprechend langsam vorangeht.
An dieser Stelle solltest du ansetzten: Wenn der User sich bereits vorher authentifiziert hat, bekommt er nur die Thumbs gezeigt die er auch aufrufen darf, dann entfällte eine zweite Prüfung.
Leichter gesagt, als getan! Denn wenn die Dateien ganz normal z.B. über http://server.de/bilder/bild1.jpg erreichbar sind, dann stellt das für mich ein erhebliches Sicherheitsrisiko dar. Deswegen _muss_ der Weg über das Skript laufen, welches prüft, ob der Benutzer berechtigt ist, die Datei laden zu dürfen und falls ja, sie ihm rüberschickt.
Deswegen geht das Ganze auch so elendig langsam von statten, denn das Skript, welches für jedes der Thumbs extra geladen wird, ist nicht persistent (auch eine Überlegung, die ich mal gemacht habe, ob man es nicht Client-Server-basiert auf der Server-Seite machen könnte) und deswegen wird bei jedem Aufruf ein ganzer Haufen Packages geladen, die Verbindung zum SQL-Server hergestellt, die Session geprüft, die Rechte geprüft und dann erst die Datei ausgegeben =(So wie es aussieht bleiben mir zwei Möglichkeiten: Skript persistent machen, sodass Dinge wie die Verbindung zum SQL-Server nicht unnötig häufig hergestellt werden müssen oder ich finde mich mit der jetzigen Ladegeschwindigkeit ab.
Oder es gibt doch eine Möglichkeit, direkt mit einer HTML-Datei Grafiken mitzuschicken... Meine Hoffnung schwindet allerdings langsam...
Trotzdem vielen Dank,
Max
-
Leichter gesagt, als getan! Denn wenn die Dateien ganz normal z.B. über http://server.de/bilder/bild1.jpg erreichbar sind, dann stellt das für mich ein erhebliches Sicherheitsrisiko dar. Deswegen _muss_ der Weg über das Skript laufen, welches prüft, ob der Benutzer berechtigt ist, die Datei laden zu dürfen und falls ja, sie ihm rüberschickt.
Es gibt auch die Möglichkeit über .htacess damit brauchst du gar nichts mehr Serverseitig zu machen, aber..
Deswegen geht das Ganze auch so elendig langsam von statten, denn das Skript, welches für jedes der Thumbs extra geladen wird, ist nicht persistent (auch eine Überlegung, die ich mal gemacht habe, ob man es nicht Client-Server-basiert auf der Server-Seite machen könnte) und deswegen wird bei jedem Aufruf ein ganzer Haufen Packages geladen, die Verbindung zum SQL-Server hergestellt, die Session geprüft, die Rechte geprüft und dann erst die Datei ausgegeben =(
.... wenn das wirklich elendig langsam geht ist etwas an deinem Skript faul. Es gibt Seiten, die wesentlich aufwendigere Dinge tun.
Ehrlich gesagt glaube ich nicht, das dein Skript langsam ist, da diese Dinge die du beschreibst völlig normal sind und in der Regel auch in kurzer Zeit (sekundenbruchteile) ablaufen. Der Flaschenhals ist fast immer die Internetverbindung.Struppi.
-
.... wenn das wirklich elendig langsam geht ist etwas an deinem Skript faul. Es gibt Seiten, die wesentlich aufwendigere Dinge tun.
Ehrlich gesagt glaube ich nicht, das dein Skript langsam ist, da diese Dinge die du beschreibst völlig normal sind und in der Regel auch in kurzer Zeit (sekundenbruchteile) ablaufen. Der Flaschenhals ist fast immer die Internetverbindung.Das Skript (bzw. das ganze System) läuft auf meinem Zweitrechner (K6-2/400, 256 MB Speicher, Debian 3.0, Apache 1.3, MySQL 3.23), der über 100MBit-Ethernet mit meinem Arbeitsrechner verbunden ist. Ich hab jetzt mal ein bisschen rumprobiert und hab die wahrscheinlich Ursache gefunden: das Package MIME::Types! Ohne Einsatz dessen lädt ein Bild in 0.2 Sekunden (gemessen mit Time::HiRes), mit dem Paket zwischen 0.8 und 1.6 Sekunden! Dazu kommt natürlich noch der Zeitaufwand beim Starten des Perl-Interpreters für jedes Bild, sodass das Ganze im Endeffekt recht lahm wird.
Als "Workaround" werd ich wohl auf MIME::Types verzichten und die Header stattdessen fest verdrahten; dann verliere ich zwar etwas Flexibilität, gewinne aber enorm an Geschwindigkeit.Grüße,
Max
-
-
hi,
An dieser Stelle solltest du ansetzten: Wenn der User sich bereits vorher authentifiziert hat, bekommt er nur die Thumbs gezeigt die er auch aufrufen darf, dann entfällte eine zweite Prüfung.
Leichter gesagt, als getan! Denn wenn die Dateien ganz normal z.B. über http://server.de/bilder/bild1.jpg erreichbar sind, dann stellt das für mich ein erhebliches Sicherheitsrisiko dar. Deswegen _muss_ der Weg über das Skript laufen, welches prüft, ob der Benutzer berechtigt ist, die Datei laden zu dürfen und falls ja, sie ihm rüberschickt.
Deswegen geht das Ganze auch so elendig langsam von statten, denn das Skript, welches für jedes der Thumbs extra geladen wird, ist nicht persistent (auch eine Überlegung, die ich mal gemacht habe, ob man es nicht Client-Server-basiert auf der Server-Seite machen könnte) und deswegen wird bei jedem Aufruf ein ganzer Haufen Packages geladen, die Verbindung zum SQL-Server hergestellt, die Session geprüft, die Rechte geprüft und dann erst die Datei ausgegeben =(So wie es aussieht bleiben mir zwei Möglichkeiten: Skript persistent machen, sodass Dinge wie die Verbindung zum SQL-Server nicht unnötig häufig hergestellt werden müssen oder ich finde mich mit der jetzigen Ladegeschwindigkeit ab.
jow, wenn das so sein soll: FastCGI
Viele Grüße, Rolf
--
SELFforum - Das Tor zur Welt!
Theoretiker: Wie kommt das Kupfer in die Leitung?
Praktiker: Wie kommt der Strom in die Leitung?
-
-