wie ist das mit file::type beim upload

[Gustl]

hi, bin grade dabei ein uploadscript mit echtzeit-fortschrittsanzeige zu schreiben, das vorwiegend für grosse mp4´s und flv´s, aber auch für jpg´s verwendet wird. das script an sich läuft. ich brauche aber detaillierte infos über die datei, bevor ich das file auf den server schreibe.

wie kann ich datei-infos vor dem schreiben auslesen und welche infos werden gesendet? (grösse, typ, spieldauer, frames, codec etc.) das wichtigste wäre erst mal der typ, die grösse kann man ja über content_length rauslesen.

ich kapier nicht wirklich was file::type macht. hilft mir das modul überhaupt (dann installier ich es) oder liest file::type nur infos, wenn die datei schon auf dem server liegt? oder gibts eine zauber.pm die meine probleme alle auf ein mal löst?

wer kann mir helfen, ich hab mich noch nie damit beschäftigt und bin ziemlich ratlos.

vielen dank

• Gustl

[hotti]

hi,

ich kapier nicht wirklich was file::type macht. hilft mir das modul überhaupt (dann installier ich es) oder liest file::type nur infos, wenn die datei schon auf dem server liegt? oder gibts eine zauber.pm die meine probleme alle auf ein mal löst?

Verstehe das Upload. Der Browser sendet eine Multipart-Message per Post (enctype="multipart/form-data"). Diese 'Datei' wird serverseitig aus STDIN gelesen, wenn Du CGI.pm verwendest, macht das CGI.pm und übernimmt auch das parsen, was nicht ganz trivial ist.

Alle Dateien, die der Browser in <input type="file"> sendet, legt CGI.pm auf dem Server temporär ab und über das CGI-Objekt bekommst Du jeweils ein Dateihandle über das name-Attribut.

D.h., die Dateien sind bereits auf dem Server.

Beispiel: input type="file" name="upfile"

  
use CGI;  
my $cgi = CGI->new;  
my $fh = $cgi->param('upfile'); # Dateihandle  
  
# Datei an einen anderen Platz kopieren  
# gleich aus dem Handle heraus  
use File::Copy;  
copy($fh, '/foo/bar/myfile'); # $! im Fehlerfall abfragen  

Den Type könntest Du so befragen:
my $type = $cgi->uploadInfo($fh)->{'Content-Type'};

Was jedoch nicht sehr verlässlich ist, das wäre zu testen, genauso wie das Ermitteln des Type mit File::Type. Letztgenanntes Modul erstellt ein eigenes Handle aus dem Dateinamen, den bekommst Du mit dem CGI-Objekt und tmpFileName() für die temporäre Datei, wo CGI.pm anlegt.

Hotti

[Gustl]

hi hotti, auf dich ist halt verlass :-)

hi,

ich kapier nicht wirklich was file::type macht. hilft mir das modul überhaupt (dann installier ich es) oder liest file::type nur infos, wenn die datei schon auf dem server liegt? oder gibts eine zauber.pm die meine probleme alle auf ein mal löst?

Verstehe das Upload. Der Browser sendet eine Multipart-Message per Post (enctype="multipart/form-data"). Diese 'Datei' wird serverseitig aus STDIN gelesen, wenn Du CGI.pm verwendest, macht das CGI.pm und übernimmt auch das parsen, was nicht ganz trivial ist.

Alle Dateien, die der Browser in <input type="file"> sendet, legt CGI.pm auf dem Server temporär ab und über das CGI-Objekt bekommst Du jeweils ein Dateihandle über das name-Attribut.

D.h., die Dateien sind bereits auf dem Server.

sind das mehrere dateien? oder nur eine datei?

ich stell mir das so vor. der browser sollte zuerst eine kleine info-datei mit allen file-infos schicken, die man dann abfragen kann bevor die hauptdatei temporär geschrieben wird. wenn bedingung a,b,x..erfüllt ist beginnt das schreiben, wenn nicht wird die infodatei gelöscht und gut is.

ich hab zuwenig ahnung davon wo dateiinfos in einer datei stehen und ob man die auslesen könnte bevor der grosse batzen geschrieben wird. aber genial wär das schon. ein dateiformat, das in den ersten x? 2048 bytes alle infos stehen hat.

"lese die ersten 2048, also alle datei-infos, und wenn passt dann mach alles rauf oder nix".

geht sowas wirklich nicht?

Beispiel: input type="file" name="upfile"

use CGI;
my $cgi = CGI->new;
my $fh = $cgi->param('upfile'); # Dateihandle

Datei an einen anderen Platz kopieren

gleich aus dem Handle heraus

use File::Copy;
copy($fh, '/foo/bar/myfile'); # $! im Fehlerfall abfragen

>   
  
ja, so ungefähr da bin ich schon.  
  

> Den Type könntest Du so befragen:  
> `my $type = $cgi->uploadInfo($fh)->{'Content-Type'};`{:.language-perl}  

»»  
  
ok, probier ich gleich. wo erfahre ich welche infos ich je dateityp auslesen kann? content-type und content-length, das kanns doch nicht gewesen sein. z.b. die typischen infos einer mp4 oder flv datei wie spiellänge in sekunden, frameanzahl, aspectratio und dergleichen. youtube etc. kanns, oder?  
  

> Was jedoch nicht sehr verlässlich ist, das wäre zu testen, genauso wie das Ermitteln des Type mit `File::Type`{:.language-perl}. Letztgenanntes Modul erstellt ein eigenes Handle aus dem Dateinamen, den bekommst Du mit dem CGI-Objekt und tmpFileName() für die temporäre Datei, wo CGI.pm anlegt.  
>   
> Hotti  
  
lernen ist irgendwie schei\*e, das wusste ich schon immer :-)  
  
- Gustl 

[hotti]

hi,

D.h., die Dateien sind bereits auf dem Server.

sind das mehrere dateien? oder nur eine datei?

Es sind soviele Dateichen, wie der Browser schickt.

ich stell mir das so vor. der browser sollte zuerst eine kleine info-datei mit allen file-infos schicken, die man dann abfragen kann bevor die hauptdatei temporär geschrieben wird. wenn bedingung a,b,x..erfüllt ist beginnt das schreiben, wenn nicht wird die infodatei gelöscht und gut is.

ich hab zuwenig ahnung davon wo dateiinfos in einer datei stehen und ob man die auslesen könnte bevor der grosse batzen geschrieben wird. aber genial wär das schon. ein dateiformat, das in den ersten x? 2048 bytes alle infos stehen hat.

"lese die ersten 2048, also alle datei-infos, und wenn passt dann mach alles rauf oder nix".

geht sowas wirklich nicht?

Es ist leider so, dass ordinäre Browser das nicht so machen, wie wir's gerne hätten ;)

Multipart/form-date ist ein Vehikel, da ist alles drin, was der Benutzer in das Formular eingibt und das sind auch die Dateien, die der Browser von der lokalen Festplatte liest. Dieser ganze Klumbatsch geht mit einem Rutsch hoch auf den Server.

Du tust gut daran, Dir das mal mit einem Testscript anzugucken, Tipp: Verwende nicht CGI.pm, das captured STDIN so dass Du nicht mehr rankommst. Zum Testen also einfach mal STDIN auslesen read STDIN, my $buffer, $ENV{CONTENT_LENGTH} und als plain/text im Browser ausgeben. Damit Du mal ein Gefühl bekommst, wie ein multipart/form-data aussieht ;)

ok, probier ich gleich. wo erfahre ich welche infos ich je dateityp auslesen kann? content-type und content-length, das kanns doch nicht gewesen sein. z.b. die typischen infos einer mp4 oder flv datei wie spiellänge in sekunden, frameanzahl, aspectratio und dergleichen. youtube etc. kanns, oder?

Dieses MPx-Geraffel hat doch dateiintern noch irgendwelche Tags versteckt, wo Du auslesen kannst. CPAN mp3

lernen ist irgendwie schei*e, das wusste ich schon immer :-)

Das wird auch niemals aufhören ;)

Hotti

[Gustl]

  
  
  my $type = $q->uploadInfo($handle)->{'Content-Type'};  
  my $lang = $q->uploadInfo($handle)->{'Content-Length'};  
  

bei einer mp4 datei kommt nur "application/octet-stream" zurück.
content_length kommt gar nichts.

bei einem jpg kommt "image/pjpeg", das stimmt.
content_length kommt ebenfalls gar nichts.

• Gustl

[hotti]

hi,

my $type = $q->uploadInfo($handle)->{'Content-Type'};
  my $lang = $q->uploadInfo($handle)->{'Content-Length'};

>   
> bei einer mp4 datei kommt nur "application/octet-stream" zurück.  
> content\_length kommt gar nichts.  
  
Zur Länge kannst Du ja mit `-s $fh`{:.language-perl} das Handle (CGI::param('name\_des\_input\_type\_file\_fields')) selbst befragen. Ggf. ein vorheriges `seek $fh, 0,0;`{:.language-perl}  
  
Ansonsten probier mal das Modul [File::Type](http://search.cpan.org/~pmison/File-Type-0.22/lib/File/Type.pm), das dürfte mehr Informationen liefern, was die Inhalte betrifft.  
  
Das Modul ist pure Perl, erstelle in deimem Lib-Verzeichnis einen Eintag /File/ und lege die Datei als Type.pm in dieses Verzeichnis, das ist alles (von CPAN die Source 'package File::Type' einfach kopieren).  
  
Viel Erfolg!  
Hotti

[CPAN]

Ansonsten probier mal das Modul File::Type, das dürfte mehr Informationen liefern, was die Inhalte betrifft.

Nein, das ist Schrott. File::LibMagic ist das beste.

[Mitleser]

Verstehe das Upload. ..Alle Dateien, die der Browser in <input type="file"> sendet, legt CGI.pm auf dem Server temporär ab ....
D.h., die Dateien sind bereits auf dem Server.

Verstehe CGI.pm

Den Fortschritt bekommt man so auf die Reihe und man könnte auch während des Uploads bereits versuchen, bereits verfügbare Bytes auszuwerten. Ich denke, die Chancen stehen nicht schlecht. ImageMagick für die Bilder und Mplayer für die Videos wäre ein Ansatz.

[hotti]

Verstehe das Upload. ..Alle Dateien, die der Browser in <input type="file"> sendet, legt CGI.pm auf dem Server temporär ab ....
D.h., die Dateien sind bereits auf dem Server.

Verstehe CGI.pm

Den Fortschritt bekommt man so auf die Reihe und man könnte auch während des Uploads bereits versuchen, bereits verfügbare Bytes auszuwerten.

Nein. Dazu müsstest Du in das HTTP(rotokoll) eingreifen, z.B. mit einem speziellen UserAgent, der aus _einem_ POST mehrere POSTs macht und die Responses zur Fortschrittanzeige auswerten kann. Machbar ist das alles, gewöhnliche Browser machen das aber nicht ;)

Hotti

[Mitleser]

Verstehe das Upload. ..Alle Dateien, die der Browser in <input type="file"> sendet, legt CGI.pm auf dem Server temporär ab ....
D.h., die Dateien sind bereits auf dem Server.

Verstehe CGI.pm

Den Fortschritt bekommt man so auf die Reihe und man könnte auch während des Uploads bereits versuchen, bereits verfügbare Bytes auszuwerten.

Nein. Dazu müsstest Du in das HTTP(rotokoll) eingreifen, z.B. mit einem speziellen UserAgent, der aus _einem_ POST mehrere POSTs macht und die Responses zur Fortschrittanzeige auswerten kann. Machbar ist das alles, gewöhnliche Browser machen das aber nicht ;)

Hotti

Schön, wie überzeugt Du mal wieder beharrlich Unsinn verzapfst. Folgendes würde in sämtlichen _gewöhnlichen_ Browsern funktionieren: Schick den Upload in einen (versteckenten)Frame. Serverseitig schreibst Du _während_ des Uploads via Upload hook die gewünschten Informationen in eine temporäre Datei. Der Client kann die Infos dann z.B. via Ajax zyklisch pollen und visualisieren.

Da essentielle Informationen am Anfang der Bild-/Videodateien stehen, sehe ich sogar für die weitere, vom OP gewünschte, Informationsauswertung gute Chancen.

[Gustl]

Da essentielle Informationen am Anfang der Bild-/Videodateien stehen, sehe ich sogar für die weitere, vom OP gewünschte, Informationsauswertung gute Chancen.

das wäre jetzt seeehr interessant. wie komm ich an die infos?

gustl

[Mitleser]

das wäre jetzt seeehr interessant. wie komm ich an die infos?

Füttere geeignete Programme mit den verfügbaren Bytes: ImageMagick auf die Bilder, Mplayer auf die Videos.

[hotti]

hi,

Schön, wie überzeugt Du mal wieder beharrlich Unsinn verzapfst.

Ach was, ich beschreibe lediglich den POST, die RFCs dazu sind steinalt ;)

Folgendes würde in sämtlichen _gewöhnlichen_ Browsern funktionieren: [..]

Das hat mit dem Browser gar nichts zu tun. Was Du beschreibst, ist das Zusammenspiel zwischen Webserver und CGI-Prozess.

Hotti

[Gustl]

hi,

Schön, wie überzeugt Du mal wieder beharrlich Unsinn verzapfst.

Ach was, ich beschreibe lediglich den POST, die RFCs dazu sind steinalt ;)

Folgendes würde in sämtlichen _gewöhnlichen_ Browsern funktionieren: [..]

Das hat mit dem Browser gar nichts zu tun. Was Du beschreibst, ist das Zusammenspiel zwischen Webserver und CGI-Prozess.

Hotti

fangts fei nicht zum raufen an ihr 2, denn wenn doch will ich auch zukucken.

jeder weiß was, und nicht alles stimmt immer bzw. wie man den anderen halt schriftlich versteht. aber darum gehts gar nicht so sehr, sondern ums selber lernen. oft brauchts nur einen schups.

• Gustl

[Mitleser]

Das hat mit dem Browser gar nichts zu tun. Was Du beschreibst, ist das Zusammenspiel zwischen Webserver und CGI-Prozess.

Was ich beschrieb, ist die funktionierende Lösung für die Fragestellung des OP - also genau das, was Du mit viel Prosa als unmöglich beschrieben hast.

[hotti]

Das hat mit dem Browser gar nichts zu tun. Was Du beschreibst, ist das Zusammenspiel zwischen Webserver und CGI-Prozess.

Was ich beschrieb, ist die funktionierende Lösung für die Fragestellung des OP - also genau das, was Du mit viel Prosa als unmöglich beschrieben hast.

Mit Heckenschützen über Prosa reden? Egal, ich versuche es noch einmal:

Das HTTP(rotokoll) lässt eine Fortschritt-Anzeige nicht zu, weil die gesamte Multipart-Message am Stück übertragen wird. Das heißt, die Response, die ein UserAgent vom Webserver bekommt, sagt aus, dass ALLES angekommen ist. Das ist die Prosa. Wenn Du das verstanden hast, schau bitte noch einmal in die Features von CGI.pm v3.63:

Neuere Versionen CGI.pm (v3.63, erfordert Perl v5.8) bieten die Möglichkeit, den vom Webserver gepufferten Datenstrom über eine eigene Callbackfunktion zu lesen.

Und das ist der Haken, die Crux, das Hook: CGI.pm bekommt einen vom Webserver gepufferten Datenstrom der Multipart-Message in STDIN. Wenn Du diesen Puffer sehen willst, brauchst Du einen zweiten UserAgent, der synchron mit dem Ersten laufen muss.

Und noch eine Überraschung wartet auf Dich, wenn Du CGI.pm verbietest, temporäre Dateien anzulegen: Das Parsen der Multipart-Message darfst Du in diesem Fall selbst übernehmen.

Wenn Du damit irgendwelche Erfolge erreichen konntest, komm raus aus Deiner Hecke und berichte darüber ;)

Hotti

[Mitleser]

Und noch eine Überraschung wartet auf Dich...

Eine Überraschung wäre es, wenn Du zur Abwechslung mal Größe beweisen und Deine Fehleinschätzungen eingestehen würdest.

[CPAN]

Das HTTP(rotokoll) lässt eine Fortschritt-Anzeige nicht zu, weil die gesamte Multipart-Message am Stück übertragen wird.

Das ist logisch falsch, aus dem Prädikat im zweiten Teilsatz kannst du nicht die Aussage im ersten folgern.

Wenn Du diesen Puffer sehen willst, brauchst Du einen zweiten UserAgent, der synchron mit dem Ersten laufen muss.

Das ist falsch. Den Pufferinhalt kriegt man gleich zu sehen, nachdem er vom Webserver entleert wurde.

Und noch eine Überraschung wartet auf Dich, wenn Du CGI.pm verbietest, temporäre Dateien anzulegen: Das Parsen der Multipart-Message darfst Du in diesem Fall selbst übernehmen.

Das ist falsch. CGI.pm übernimmt das Parsen und stellt auf jeden Fall die MIME-dekodierten Ströme im Callback zur Verfügung.

Wenn Du damit irgendwelche Erfolge erreichen konntest, komm raus aus Deiner Hecke und berichte darüber ;)

Mir wär's lieber, wenn du nicht immer so viel unwahres in die Welt setzen würdest. Überprüfe gefälligst deine Behauptungen durch Code! Es wird langsam zur Zumutung, dass du immer widerlegt und belehrt werden musst.

[hotti]

hi Du,

Wenn Du diesen Puffer sehen willst, brauchst Du einen zweiten UserAgent, der synchron mit dem Ersten laufen muss.

Das ist falsch. Den Pufferinhalt kriegt man gleich zu sehen, nachdem er vom Webserver entleert wurde.

Ohne UA siehst Du gar nichts. Dein UA wartet auf die Response für den POST. Also brauchst Du einen zweiten UA, der den Puffer anzeigt. Möglicherweise wirst Du diesen zweiten UA über Ajax realisieren, der muss jedoch synchron laufen. Hast Du das schonmal gemacht, dann zeige Deinen Code.

Und noch eine Überraschung wartet auf Dich, wenn Du CGI.pm verbietest, temporäre Dateien anzulegen: Das Parsen der Multipart-Message darfst Du in diesem Fall selbst übernehmen.

Das ist falsch. CGI.pm übernimmt das Parsen und stellt auf jeden Fall die MIME-dekodierten Ströme im Callback zur Verfügung.

Zeige Deine Callbackfunktion.

Überprüfe gefälligst deine Behauptungen durch Code!

Sag ich doch ;)

Schönen Sonntag!

[Gustl]

Serverseitig schreibst Du _während_ des Uploads via Upload hook die gewünschten Informationen in eine temporäre Datei.

auf die gefahr hin dass ich nerve o-)

ich hab festgestellt dass im unterprogramm sub hook my $length = $ENV{'CONTENT_LENGTH'}; die spätere gesamtgrösse abgefragt wird. im sub wird die session-datei geschrieben. diese datei kann ich auslesen von wo aus ich will. in dieser datei steht acuh die spätere gesamtgrösse.

vermutlich bin ich wieder komplett aufm holzweg, aber: wenn mir die spätere grösse der datei schon anfangs bekannt ist, dann müsste ich doch den gesamten download irgendwie stoppen können, bevor die ganze datei oben ist. "wenn spätere grösse > 52428800 Byte (50MB) dann brich das laden ab".

wie geht das bzw. gehts überhaupt? ich meine, wenn z.b. die verbindung während des uploads abbricht dann muss das tempfile ja auch automatisch gekillt werden. das kann nicht das problem sein.

der parameter $use_tempfile im hook, was macht der genau? wenn ich den auf false setzte, der download läuft docht weiter, oder?

The $use_tempfile field is a flag that lets you turn on and off CGI.pm's use of a temporary disk-based file during file upload. If you set this to a FALSE value (default true) then $q->param('uploaded_file') will no longer work, and the only way to get at the uploaded data is via the hook you provide.

mein englisch ist zu eingerostet dafür...

gruss gustl

[Mitleser]

The $use_tempfile field is a flag that lets you turn on and off CGI.pm's use of a temporary disk-based file during file upload. If you set this to a FALSE value (default true) then $q->param('uploaded_file') will no longer work, and the only way to get at the uploaded data is via the hook you provide.

Genau das scheinst Du zu wollen. Es wird _keine_ temporäre Datei erzeugt und Du bist im hook selbst dafür verantwortlich, was mit den Bytes passiert. Damit steht es Dir auch frei das Script geordnet zu beenden, wenn Dir die Bytes nicht gefallen.

[Gustl]

Den Fortschritt bekommt man so auf die Reihe und man könnte auch während des Uploads bereits versuchen, bereits verfügbare Bytes auszuwerten.

Nein. Dazu müsstest Du in das HTTP(rotokoll) eingreifen, z.B. mit einem speziellen UserAgent, der aus _einem_ POST mehrere POSTs macht und die Responses zur Fortschrittanzeige auswerten kann. Machbar ist das alles, gewöhnliche Browser machen das aber nicht ;)

fortschritt: also da läuft im html-formular ein ping im javascript, nachdem der upload angestossen wurde. der stupst das uploadscript sagen wir alle 500ms an, die grösse der temporären datei zurück zu geben. dann (oder vorher?) ein xml-http-request mit ajax. im uploadscript wird das cgi-objekt mit &hook gestartet. in sub hook wird die grösse ausgelesen, die session-id eingelesen die vom form kommt, eine sessiondatei geschrieben, die wieder ausgelesen wird etc.

ich kapier nur 21,5% davon, aber laufen TUT. man kann gemütlich das wachsen der datei in einem balkendiagramm ankucken. genial.

ich find nur die anleitung nicht mehr, sonst würd ich euch den link posten.

gruss gustl

[hotti]

hi,

was zum testen online oder Eigenbedarf (Code steht auf der Seite):
Upload

Hinweis: Serverseitig wird nichts gespeichert. Der Original-POST wird im Browser ausgegeben, um mal zu zeigen wie eine Multipart-Message aussieht.

Nehmt zum Testen ne Textdatei.

Hotti

[Gustl]

was zum testen online oder Eigenbedarf (Code steht auf der Seite):
Upload

hi hotti, da wär es jetzt gut zu erfahren, was der browser genau alles vorab sendet. CONTENT_LENGTH ist ja auch schon vorab da, damit man verhindern kann dass einer einen 100 gigatonnen granithaufen schickt.

CONTENT_LENGTH ist allerdings die komplette datenmenge, oder? also datei, text, weihnachtsbaum, bier und bratwurst. die grösse der einzelnen datei explizit kann ich erst abfragen, wenn sie temporär da ist. lieg ich da richtig? das heisst, dass auch andere dateiinfos nur ausgelesen werden können wenn alles übertragen ist ...

schön langsam sickerts auch bei mir rein.

gruss gustl

[hotti]

Moin;

was zum testen online oder Eigenbedarf (Code steht auf der Seite):
Upload

hi hotti, da wär es jetzt gut zu erfahren, was der browser genau alles vorab sendet. CONTENT_LENGTH ist ja auch schon vorab da, damit man verhindern kann dass einer einen 100 gigatonnen granithaufen schickt.

Jein, verhindern kannst Du das nicht. Dein Script liegt ja hinter dem Webserver, der ist das Opfer ;)

Sobald Deinem Script CONTENT_LENGTH bekannt ist, hat der Webserver schon alles auf dem Buckel.

CONTENT_LENGTH ist allerdings die komplette datenmenge, oder? also datei, text, weihnachtsbaum, bier und bratwurst.

ja, genau: Die komplette Multipart-Message

die grösse der einzelnen datei explizit kann ich erst abfragen, wenn sie temporär da ist. lieg ich da richtig?

Goldrichtig. Also, erst dann, wenn der CGI-Parser sein Werk getan hat.

das heisst, dass auch andere dateiinfos nur ausgelesen werden können wenn alles übertragen ist ...

Korrekt!

Kleine Ergänzung: Die Angabe {Content-Type}, vom CGI-Parser geliefert, ist das was der Browser sendet, das ist nicht verlässlich. Du tust gut daran, eine eigene Prüfung, z.B. mit File::Type zu machen.

Hotti

[Gustl]

Kleine Ergänzung: Die Angabe {Content-Type}, vom CGI-Parser geliefert, ist das was der Browser sendet, das ist nicht verlässlich. Du tust gut daran, eine eigene Prüfung, z.B. mit File::Type zu machen.

ok. ich schau mir zuerst die dateiendung an, wenn die stimmt dann lass ich das upload temporär zu. bevor ich aber an die endgültige position schreibe, prüfe ich die tempdatei nochmal mit file::type, denn es kann ja sein dass der anwender einfach eine *.bomb mit *.mp4 tarnt.

ich frag mich wie sicher die dateiprüfung mit file::type im endeffekt ist. wenn sich einer wirklich gut auskennt (was ich definitiv nicht kann), dann kann er mir doch auch ne bombe für ein stück käsekucken verkaufen. kann eine tempdatei schaden anrichten, schon bevor ich sie an die richtige stelle kopiere? ne, oder? sonst könnte man ja jede maschine im handumdrehen knacken.

• Gustl

[hotti]

hi,

ich frag mich wie sicher die dateiprüfung mit file::type im endeffekt ist. wenn sich einer wirklich gut auskennt (was ich definitiv nicht kann), dann kann er mir doch auch ne bombe für ein stück käsekucken verkaufen. kann eine tempdatei schaden anrichten, schon bevor ich sie an die richtige stelle kopiere? ne, oder? sonst könnte man ja jede maschine im handumdrehen knacken.

Schau Dir das Script an, was ich gestern abend erstellt habe. Anschaulicher gehts nicht, und mal so ganz nebenbei bemerkt: Anschaulicher habe ich das auch noch nirgendwo so gesehen.

Der Webserver bekommt eine Multipart-Message. Das sind, vereinfacht ausgedrückt, mehrere Dateien in einer Datei. Das heißt, die Informationen zu einer Einzel-Datei kannst Du erst bekommen, wenn die Multipart-Message in seine Einzelteile zerlegt ist.

Dieses Zerlegen macht der Parser (CGI.pm) und der kann das erst machen, wenn die Multipart-Message komplett übertragen wurde. Unglücklicherweise ist eben diese Multipart-Message zeichenorientiert strukturiert und muss zum Parsen komplett, am Stück, als Ganzes in den Hauptspeicher gelesen werden, die Komponenten, soweit als file kenntlich, liegen im Ergebnis dessen temporär auf der Festplatte des Servers.

Würde es Browser geben, die eine Multipart-Message nicht zeichenorientiert sondern byteorientiert strukturiert senden würden, könnte das Parsen bereits beim Lesen der Byte-Sequenz aus dem Socket heraus gemacht werden. Das hätte zur Folge, dass Meta-Informationen schon verfügbar sind, bevor die gesamte Multipart-Message übertragen ist und als hübscher kleiner Nebeneffekt wird dazu weniger RAM verschwendet.

Vermutlich wird es irgendwann mal sowas geben, möglicherweise treibt der Mobile-Bereich die Entwicklung voran.

bis dahin müssen wir uns mit dem rumärgern, was da ist ;)

Hotti

PS: MIME ist auch Schrott.

[Mitleser]

Dieses Zerlegen macht der Parser (CGI.pm) und der kann das erst machen, wenn die Multipart-Message komplett übertragen wurde. Unglücklicherweise ist eben diese Multipart-Message zeichenorientiert strukturiert und muss zum Parsen komplett, am Stück, als Ganzes in den Hauptspeicher gelesen werden, die Komponenten, soweit als file kenntlich, liegen im Ergebnis dessen temporär auf der Festplatte des Servers.

Ja, ich habe folgendes gelesen und verstanden:

http://search.cpan.org/~markstos/CGI.pm-3.63/lib/CGI.pm#Progress_bars_for_file_uploads_and_avoiding_temp_files

Bitte ankreuzen:

[ ] Ja
[ ] Nein

[Mitleser]

schön langsam sickerts auch bei mir rein.

Lass es lieber direkt in den Orkus durchsickern, Du wurdest fehlinformiert.

[Gustl]

hi, bin grade dabei ein uploadscript mit echtzeit-fortschrittsanzeige zu schreiben.

ich nehme mir was vor wovon ich keine ahnung habe. wenn ich es schaffe bin ich meist ein stück gescheiter.

das ding läuft, trallali, aber jetzt muss ich die feinheiten ausfeilen.

mächtiger thread wird das :-)

jetzt sag ich erst mal danke und wünsche allen schöne feiertage. werde den kasten die nächsten tage nicht anrühren, sonst träume ich noch in I O.

also bis dann.

• Gustl

ps: kann mir eingentlich wer sagen wie ich mit nem regulärem ausdruck innerhalb eines textes überlange zeichenketten ohne leerzeichen aufspüren und in kleinere zerbröslen kann?