Unbuffered Upload
Elexender
- php
Hallo,
ich muss mal richtig grosse Dateien auf den Server hoch laden und suche nach einer Möglichkeit dies zu tun, ohne dass die Daten in RAM geladen werden.
Abstrakt:
Angenommen der Server hat 500 MB RAM. Es kommen 10 User (nicht unbedingt gleichzeitig) und laden Dateien mit der Größe von 100 MB hoch. Insgesamt also 1 GB. In diesem Fall wird RAM also einfach nicht ausreichen.
(Der Upload von 100 MB dauert ja eine Weile und die anderen 10 User kommen irgendwann in diesem Zeitraum und laden weitere Dateien hoch.)
Frage:
Wie kann ich es veranlassen, dass die Dateien nicht in RAM geladen werden. Bzw. wie kann ich es am elegantesten erledigen, dass der RAM ab und zu mal auf Disk übertragen wird. Oder vielleicht gibt es da eine andere Methode. Auf jeden Fall soll das ganze ohne Performance-Einbüsen geschehen.
Gruss Elex.
hi,
Angenommen der Server hat 500 MB RAM. Es kommen 10 User (nicht unbedingt gleichzeitig) und laden Dateien mit der Größe von 100 MB hoch.
Wieso hast du den Themenbereich PHP gewählt?
Du willst doch wohl Dateien dieser Größenordnung nicht über einen HTTP-Upload hochladen?
HTTP ist für solche Datenmengen m.E. ungeeignet.
FTP bietet sich an.
gruß,
wahsaga
Hi,
HTTP ist für solche Datenmengen [RR: 500MB] m.E. ungeeignet.
warum?
Gruß
Schlemmi
hi,
HTTP ist für solche Datenmengen [RR: 500MB] m.E. ungeeignet.
warum?
Weil es nicht dafür konzipiert wurde, solche Datenmengen zu handeln - ganz im Gegensatz zum FTP.
gruß,
wahsaga
Hello,
HTTP ist für solche Datenmengen [RR: 500MB] m.E. ungeeignet.
warum?
Weil es nicht dafür konzipiert wurde, solche Datenmengen zu handeln - ganz im Gegensatz zum FTP.
Und wärest Du eventuell bereit dazu, den konzeptionellen Unterschied darzulegen?
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hi,
HTTP ist für solche Datenmengen [RR: 500MB] m.E. ungeeignet.
warum?
Weil es nicht dafür konzipiert wurde, solche Datenmengen zu handeln - ganz im Gegensatz zum FTP.
gibt es einen konkreten Grund grössere Datenmengen nicht per HTTP zu übertragen (eine für den o.g. Zweck gegebene Server-Client Struktur vorausgesetzt).
Gruß
Schlemmi
Hello,
gibt es einen konkreten Grund grössere Datenmengen nicht per HTTP zu übertragen (eine für den o.g. Zweck gegebene Server-Client Struktur vorausgesetzt).
Ich könnte mir vorstellen, dass Wahsaga hier auf die Möglichkeit des "Wiederaufsetzens" anspielt, die FTP bietet, HTTP aber eben explizit nicht. Bei HTTP ist dies in eine tiefere Schicht verlagert und damit nicht willentlich steuerbar.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo!
gibt es einen konkreten Grund grössere Datenmengen nicht per HTTP zu übertragen (eine für den o.g. Zweck gegebene Server-Client Struktur vorausgesetzt).
Ich hab letztens ein paar Hunder Kilo Gartenerde geholt. Rat mal, was der Grund dafür war, dass ich diese nicht mit meinem VW Polo geholt habe, sondern dass ich mir dafür ein Auto mit Anhänger ausgebort habe?
Richtig: Mein Polo ist nicht dafür gebaut. Auch wenns notfalls sicher ginge.
HTTP steht für Hypter Text Transfer Protocol, FTP für File Transfer Protocol.
Es gibt für gewisse Anforderungen einfach gewisse Methoden und Verfahren.
mfg
frafu
... sondern dass ich mir dafür ein Auto mit Anhänger ausgebort habe?
Ich hab das Auto natürlich nicht ausgebo(h)rt. Ich habs nur ausgeborgt! :-)
mfg
frafu
Hello,
Es gibt für gewisse Anforderungen einfach gewisse Methoden und Verfahren.
Und wo _genau_ liegt da jetzt Deiner Meinung nach der Unterschied?
Hat HTTP eine schwächere Hinterachse (Backboone) als FTP und wodrch macht sich das dann ggf. bemerkbar? Oder kann HTTP nicht alle Transportgutarten behandeln?
Könnte es ventuell auch sein, dass Du den Unterschied gar nicht erklären kannst? :-)
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo!
Es gibt für gewisse Anforderungen einfach gewisse Methoden und Verfahren.
Und wo _genau_ liegt da jetzt Deiner Meinung nach der Unterschied?
Hat HTTP eine schwächere Hinterachse (Backboone) als FTP und wodrch macht sich das dann ggf. bemerkbar? Oder kann HTTP nicht alle Transportgutarten behandeln?
Nicht alles was hinkt ist ein Vergleich.
Aber zb. kann man bei FTP einen agebrochenen Up/Download wieder aufnehmen.
mfg
frafu
Hello,
Und wo _genau_ liegt da jetzt Deiner Meinung nach der Unterschied?
Hat HTTP eine schwächere Hinterachse (Backboone) als FTP und wodrch macht sich das dann ggf. bemerkbar? Oder kann HTTP nicht alle Transportgutarten behandeln?Nicht alles was hinkt ist ein Vergleich.
Aber zb. kann man bei FTP einen agebrochenen Up/Download wieder aufnehmen.
Und woran liegt das wohl?
Was meisnt Du?
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hi Tom,
Und woran liegt das wohl?
Was meisnt Du?
Warum fragst du immer und erklärst es nicht einfach, da _du_ den Unterschied doch offensichtlich weist? Meinst du die Aufforderungen an andere es zu erklären bringen hier irgendjemanden weiter?
MfG, Dennis.
Hallo!
Und woran liegt das wohl?
Was meisnt Du?
An der unterschiedlichen Implementierung? Und warum wurden sie unterschiedlich implementiert? Weil sie für verschiedene Arten von Anwendungen sind.
Wie die Protokolle im Detail arbeiten, weiß ich leider nicht mehr auswendig. Müsste ich nachlesen.
mfg
frafu
Hello,
Wie die Protokolle im Detail arbeiten, weiß ich leider nicht mehr auswendig. Müsste ich nachlesen.
Und wenn Du uns die Unterschiede nebst zeitlichen Entwicklungsschritten erklären könntest, dann häten wir eine greifbare Aussage.
Ich erinnere nochmal. Auslöser der Diskussion war die These: FTP eigenet sich besser für den Upload großer Dateien als HTTP.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo,
gibt es einen konkreten Grund grössere Datenmengen nicht per HTTP zu übertragen (eine für den o.g. Zweck gegebene Server-Client Struktur vorausgesetzt).
weiter unten im Thread wurden ja schon welche genannt:
+ HTTP: unproblematischer bei einigen Firewalls, da bei FTP auch
der Server von sich aus eine Verbindung zum Client aufbaut
+ FTP: unterbrochene Transfers können fortgesetzt werden
HTTP kann das nicht
So, und jetzt noch ein paar pro FTP:
+ FTP: arbeitet direkt auf Datei- und nicht auf Ressourcenebene
+ FTP: braucht keine Scriptunterstützung auf der Serverseite
+ FTP: kann Dateien direkt im Binärformat übertragen und spart damit
25% Übertragungsvolumen gegenüber HTTP-Upload, bei dem die
Daten MIME-codiert (base64) übertragen werden. HTTP kann nur
beim Download uncodierte Binärdaten übertragen
Es gibt bestimmt noch mehr Argumente, aber die fallen mir nicht spontan ein.
Schönen Abend noch,
Martin
Hallo,
So, und jetzt noch ein paar pro FTP:
- FTP: arbeitet direkt auf Datei- und nicht auf Ressourcenebene
Mit der Maßgabe, daß z. B. PHP den Upload annimmt, ist dies bei
HTTP nicht anders
- FTP: kann Dateien direkt im Binärformat übertragen und spart damit
25% Übertragungsvolumen gegenüber HTTP-Upload, bei dem die
Daten MIME-codiert (base64) übertragen werden. HTTP kann nur
beim Download uncodierte Binärdaten übertragen
Das ist Unsinn. HTTP hat nichts mit Mails und den dort üblichen
7bit-Übertragungen zutun.
Ein normaler Uploade sieht so aus:
POST / HTTP/1.1
Host: 127.0.0.1:1100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.12) Gecko/20060122
Accept: application/xml,application/xhtml+xml;q=0.9,text/xml,text/html,text/plain;q=0.8,text/*;q=0.7,image/*;q=0.5,*/*;q=0.3
Accept-Language: de,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------13651805401540383426304089172
Content-Length: 3564
-----------------------------13651805401540383426304089172
Content-Disposition: form-data; name="file"; filename="arch"
Content-Type: application/octet-stream
aUåèèàèÃÿ5ÿ%ÿ%héàÿÿÿÿ%éÐÿÿÿÿ%héÀÿÿÿÿ%h▒é°ÿÿÿ1í^áäðPTRhhQVèÇÿÿÿôUåSè[Ã×RüÿÿÿÀtÿÐX[ÉÃUå=tibc.so.6perrorputsuname_IO_stdin_used__libc_start_mainGLIBC_2.0$ii
ëÀ£ÿÒ¡ÒuëÆÉÃUå¡Àt!¸Àt▒Ç$è
|û÷¶¿ÉÃUåì¨äðhþÿÿì$èûþÿÿÀtÇ$èËþÿÿɸÃlÿÿÿ$èÆþÿÿÉ1ÀÃUåWV1öSèÃçì
èeþÿÿÿÿÿÿÿÿEð)ÐÁø9Æs×ÿ²EðFú)øÁø9ÆrîÄ
[^_ÉÃUåì▒]ôuøè?Ã}ü³ÿÿÿ»ÿÿÿ)þÁþëvÿ·Nþÿu÷´&è?]ôuø}üÉÃ$ÃUåS컡ëëÿÐøÿuôX[]ÃUåSè[ÃPèVþÿÿY[ÉÃarchÿÿÿÿÿÿÿÿ$
h à
k
ûÿÿoþÿÿÿÿÿoðGCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)GCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)GCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)GCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)GCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)GCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)GCC: (GNU) 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8).shstrtab.interp.note.ABI-tag.hash.dynsym.dynstr.gnu.version.gnu.version_r.rel.dyn.rel.plt.init.text.fini.rodata.eh_frame.ctors.dtors.jcr.dynamic.got.got.plt.data.bss.comment
4H !h4'
k7ÿÿÿDþÿÿ S \¸ À
tx¥PªT³p eà
øPkPäq4▒wP
|¾|²Ç
-----------------------------13651805401540383426304089172--
Gruß aus Berlin!
eddi
Hallo eddi,
- FTP: arbeitet direkt auf Datei- und nicht auf Ressourcenebene
Mit der Maßgabe, daß z. B. PHP den Upload annimmt, ist dies bei
HTTP nicht anders
ja, einverstanden.
- FTP: kann Dateien direkt im Binärformat übertragen und spart damit
25% Übertragungsvolumen gegenüber HTTP-Upload, bei dem die
Daten MIME-codiert (base64) übertragen werden. HTTP kann nur
beim Download uncodierte Binärdaten übertragenDas ist Unsinn. HTTP hat nichts mit Mails und den dort üblichen
7bit-Übertragungen zutun.
Hier irren Euer Ehren. Gut, HTTP selbst unterliegt dieser Einschränkung nicht. Aber ein HTTP-Upload wird ja meist im Rahmen eines HTML-Formulars ausgeführt. In diesem Zusammenhang hatte ich vor ein paar Tagen schon einmal recherchiert.
Ein normaler Uploade sieht so aus:
[...]
Content-Type: multipart/form-data; boundary=---------------------------13651805401540383426304089172
Content-Length: 3564-----------------------------13651805401540383426304089172
Content-Disposition: form-data; name="file"; filename="arch"
Content-Type: application/octet-stream
Das ist ein zulässiger HTTP POST Request - aber nicht im Zusammenhang mit einem HTML-Formular.
So long,
Martin
Re:
Das ist Unsinn. HTTP hat nichts mit Mails und den dort üblichen
7bit-Übertragungen zutun.Hier irren Euer Ehren. Gut, HTTP selbst unterliegt dieser Einschränkung nicht. Aber ein HTTP-Upload wird ja meist im Rahmen eines HTML-Formulars ausgeführt.
Zeige mir einen Request eines Browsers, der mindestens ein Binärfile enthält und durch ein HTML-Formular zustande kam, der als Codierung base64 nutzt, dann wird sich "Euer Ehren" auch zu "Eurer Gnaden" transformieren ;)
Das ist ein zulässiger HTTP POST Request - aber nicht im Zusammenhang mit einem HTML-Formular.
Spaß beiseite; wie glaubst Du habe ich sonst diesen Request erzeugt? Das ist der Request meines Browsers an einen Testdämon. Aufgerufen wurde dieser durch senden von Formulardaten.
RFC 2045 bestimmt zwar den erheblichen Content-Type es Request-Body, schreibt HTTP aber noch lange nicht vor 7bit-Übertragungen zu nutzen.
Gruß aus Berlin!
eddi
Hallo eddi,
Spaß beiseite; wie glaubst Du habe ich sonst diesen Request erzeugt? Das ist der Request meines Browsers an einen Testdämon. Aufgerufen wurde dieser durch senden von Formulardaten.
Dann hält er sich nicht an die Regeln der HTTP-Spec für den Formularversand, die für die Codierung von Dateien in multipart/form-data ausdrücklich auf RFC 2045 verweist. Und die bietet nur Quoted Printable und base64 als Optionen an (Abschnitt 6.7 und 6.8 der RFC).
RFC 2045 bestimmt zwar den erheblichen Content-Type es Request-Body, schreibt HTTP aber noch lange nicht vor 7bit-Übertragungen zu nutzen.
Von 7bit-Übertragung hab ich auch nix gesagt, das warst du selbst. Nur davon, dass als Codierung wahlweise base64 oder Quoted Printable zu verwenden ist. Und base64, das ich bei Binärdaten vorziehen würde, bildet nun mal jeweils 3 Byte Originaldaten auf 4 Zeichen Transfer-Stream ab, die dann bei heute üblichen Systemen 4 Bytes sind.
Ergo bläht sich die Datenmenge beim (korrekten) Upload über ein HTML-Formular um etwa 33% gegenüber der ursprünglichen Dateigröße auf.
Schönen Abend noch,
Martin
Re:
Spaß beiseite; wie glaubst Du habe ich sonst diesen Request erzeugt? Das ist der Request meines Browsers an einen Testdämon. Aufgerufen wurde dieser durch senden von Formulardaten.
Dann hält er sich nicht an die Regeln der HTTP-Spec für den Formularversand, die für die Codierung von Dateien in multipart/form-data ausdrücklich auf RFC 2045 verweist.
Lies bitte im ersten verwiesenen Dokument, ob Du dort bei der Header-Erläuterung etwas von Content-Entcoding findest.
Und die bietet nur Quoted Printable und base64 als Optionen an (Abschnitt 6.7 und 6.8 der RFC).
6.1. Content-Transfer-Encoding Syntax
The Content-Transfer-Encoding field's value is a single token
specifying the type of encoding, as enumerated below. Formally:
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
These values are not case sensitive -- Base64 and BASE64 and bAsE64
are all equivalent. An encoding type of 7BIT requires that the body
is already in a 7bit mail-ready representation. This is the default
value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
Sieht nach mehr aus, als _nur_ Quoted Printable und base64.
Im Übrigen erachte ich RFC 2388 hier als maßgeblich und in der ist nachzulesen:
3. Definition of multipart/form-data
[...]
Each part may be encoded and the "content-transfer-encoding" header
supplied if the value of that part does not conform to the default
encoding.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
Ich gestehe Dir aber zu, daß in den RFCs 2045 und 2388 _nicht explizit_ auf RFC 2119 verwiesen wird. Meine hypertolle Buddelschippe (alias Mozilla) hier als nicht standardkonform zu verunglimpfen - wie frech! (Ich hoffe es kommt bei Dir als die sarkastische Übertreibung, die wir im eigentlichen gerade betreiben, auch an ;)
RFC 2045 bestimmt zwar den erheblichen Content-Type es Request-Body, schreibt HTTP aber noch lange nicht vor 7bit-Übertragungen zu nutzen.
Von 7bit-Übertragung hab ich auch nix gesagt, das warst du selbst. Nur davon, dass als Codierung wahlweise base64 oder Quoted Printable zu verwenden ist. Und base64, das ich bei Binärdaten vorziehen würde, bildet nun mal jeweils 3 Byte Originaldaten auf 4 Zeichen Transfer-Stream ab, die dann bei heute üblichen Systemen 4 Bytes sind.
Ergo bläht sich die Datenmenge beim (korrekten) Upload über ein HTML-Formular um etwa 33% gegenüber der ursprünglichen Dateigröße auf.
Zum einen reden die von Dir referenzierten RFCs hier von einer 7bit-Übertragung, zum anderen bräuchte man solche Kodierungen sonst nicht. Das base64 ca 33% mehr hat - dem stimme ich ja gerne zu.
Im Übrigen auch meine Sandkastenförmchen (alias Opera und Konqueror) sollen dann wohl auch nicht standardkonform sein?!
POST / HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686; en) Opera 8.52
Host: 127.0.0.1:1100
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: de,en;q=0.9
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Expect: 100-continue
Connection: Keep-Alive
Content-Length: 57750
Content-Type: multipart/form-data; boundary=----------eqx0DT3WvH218uVOaBTJRM
------------eqx0DT3WvH218uVOaBTJRM
Content-Disposition: form-data; name="file"; filename="cp"
Content-Type: application/octet-stream
POST / HTTP/1.1
Connection: Keep-Alive
Pragma: no-cache
Cache-control: no-cache
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: de, en
Host: 127.0.0.1:1100
Content-Type: multipart/form-data; boundary=----------2wVLziHtWLWAiGAwA46gbcATx8aFriKudpFcWUT2pyDWELQOQX317DU
Content-Length: 17717
------------2wVLziHtWLWAiGAwA46gbcATx8aFriKudpFcWUT2pyDWELQOQX317DU
Content-Disposition: form-data; name="file"; filename="cat"
Content-Type: application/x-executable
Mach am besten Tests mit Formularen und sende sie an einen Testdämon.
Gruß aus Berlin!
eddi
Hallo eddi,
ich bin in der Zwischenzeit nochmal in mich gegangen - und in die Doku.
6.1. Content-Transfer-Encoding Syntax
[...]
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
Ich habe anhand der Überschriften gesehen, dass nur die Abschnitte 6.7 und 6.8 konkrete Codierungen behandeln, also bin ich davon ausgegangen, dass nur diese beiden in Frage kommen. Das war wohl mein Hauptfehler.
Da würde ich dann aber auch die Autoren der RFC 2045 kritisieren: Wenn von einer Liste von sieben verschiedenen Codierungen nur zwei konkret in einem Kapitel beschrieben werden, dann *muss* das ja einen falschen Eindruck machen.
- MAY This word, or the adjective "OPTIONAL", mean that ...
Danke, ich bin der englischen Sprache mächtig - gut genug, um gelegentlich von Amerikanern für einen Einheimischen gehalten zu werden. Die Bedeutung von "MAY" ist mir daher durchaus geläufig; mir ist klar, dass es sich nicht nur um einen Monatsnamen handelt. ;-)
Ich gestehe Dir aber zu, daß in den RFCs 2045 und 2388 _nicht explizit_ auf RFC 2119 verwiesen wird. Meine hypertolle Buddelschippe (alias Mozilla) hier als nicht standardkonform zu verunglimpfen - wie frech! (Ich hoffe es kommt bei Dir als die sarkastische Übertreibung, die wir im eigentlichen gerade betreiben, auch an ;)
Durchaus, ja. :-)
Ich schätze Mozilla und seine Gefährten (Firefox, T-Bird) als vorbildliche und standardkonforme Lösungen, auch wenn vor allem der Firefox in Sachen Alltagstauglichkeit nicht ganz mit Opera und IE mithalten kann.
Im Übrigen auch meine Sandkastenförmchen (alias Opera und Konqueror) sollen dann wohl auch nicht standardkonform sein?!
Naja, wenn man von zwei auf sieben erweitert, dann schon ...
Mach am besten Tests mit Formularen und sende sie an einen Testdämon.
In einer ruhigen, gelangweilten Stunde mach ich das vielleicht mal. :-)
Gute Nacht einstweilen,
Martin
Hello,
ich habe Euren Dialog hier so leidlich mitgelesen.
Da bleibt für mich jetzt aber noch die Frage nach dem Mechanismus im Browser.
Wenn man mittels HTTP Dateien uploaded, werden die dann im Browser auch erst komplett behandelt (codiert), so wie es bei eMail i.d.R. geschieht, oder werden sie on-the-fly eingefügt?
Worauf ich hinaus will: es könnte dann ggf. nicht auf dem Server, sondern auf dem Client Schwierigkeiten geben mit dem Speicherplatz. Bzw., das arme Kerlchen muss eben swapen, sofern er eine so große Swap-Datei zur Verfügung hat.
Ich habe da ja mal dieses Multiupload-Formular mittels JavaScript gebastelt...
Das benutze ich an vielen Stellen für Bilduploads. Ich konnte da noch nicht erkennen, dass der Browser zickt. Nur der Server steigt eben irgendwann aus, wenn ihm der Request zu groß wird.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo,
Da bleibt für mich jetzt aber noch die Frage nach dem Mechanismus im Browser.
Wenn man mittels HTTP Dateien uploaded, werden die dann im Browser auch erst komplett behandelt (codiert), so wie es bei eMail i.d.R. geschieht, oder werden sie on-the-fly eingefügt?
das ist ja eben der Knackpunkt. Meinen Tests nach findet eben keine Konvertierung der Datein statt. Auch auf Seiten PHPs (main/rfc1867.c) wird der Header "Content-Transfer-Encoding" weder gesucht, noch verarbeitet.
Gruß aus Berlin!
eddi
Hello,
Da bleibt für mich jetzt aber noch die Frage nach dem Mechanismus im Browser.
Wenn man mittels HTTP Dateien uploaded, werden die dann im Browser auch erst komplett behandelt (codiert), so wie es bei eMail i.d.R. geschieht, oder werden sie on-the-fly eingefügt?das ist ja eben der Knackpunkt. Meinen Tests nach findet eben keine Konvertierung der Datein statt. Auch auf Seiten PHPs (main/rfc1867.c) wird der Header "Content-Transfer-Encoding" weder gesucht, noch verarbeitet.
Das hieße also, das HTTP-Uploads auf jeden Fall 8-Bit transparente Transfersysteme erwarten.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Re:
Das hieße also, das HTTP-Uploads auf jeden Fall 8-Bit transparente Transfersysteme erwarten.
PHP jedenfalls ;)
Gruß aus Berlin!
eddi
Hello,
Das hieße also, das HTTP-Uploads auf jeden Fall 8-Bit transparente Transfersysteme erwarten.
PHP jedenfalls ;)
Der Browser ja auch, wenn Du bisher keinen gefunden hast, der die Dateien aus dem
<input type="file" > codieren will.
Harzliche Grüße vom Berg
http://www.annerschbarrich.de
Tom
Hallo.
Danke, ich bin der englischen Sprache mächtig - gut genug, um gelegentlich von Amerikanern für einen Einheimischen gehalten zu werden.
Na, wenn das keine Auszeichnung ist, ...
MfG, at
Es ist wirklich alles eine sehr schöne Diskussion. Nun musste ich aber die Dateien hoch laden. Wie das geht ist egal. Es muss über ein HTML-Formular geschehen. Wenn das über FTP geht, dann bitte Link oder Beispiel posten. Amsonsten erklärt mir wie ich das über HTTP mache.
Danke.
Hallo!
Es ist wirklich alles eine sehr schöne Diskussion. Nun musste ich aber die Dateien hoch laden. Wie das geht ist egal. Es muss über ein HTML-Formular geschehen. Wenn das über FTP geht, dann bitte Link oder Beispiel posten. Amsonsten erklärt mir wie ich das über HTTP mache.
Das Problem, wenn du die Datei per HTTP uploadest, gibt der Browser (zumindest kein mir bekannter) einen Feedback, wieviel er schon upgeloaded hat.
Also selbst wenn der Server so große Files entgegennimmt, ist es nicht benutzerfreundlich, wenn der Browser einfach so tut, als würde er nichts tun. Du weißt nicht, ist er jetzt in 3sec fertig oder erst in 3 Tagen.
Über ein HTML Formular kannst du keinen FTP Upload machen.
Ich hab ein ähnliches Problem gelöst, in dem ich ein FTP Applet geschrieben habe, dass ich dann in die Seite eingebunden habe. Der User kann einfach Dateien aus seinem Explorer (oder was auch immer) per Drag & Drop auf das Applet ziehen und das Applet erledigt den Fileupload.
Damit importiere ich Bilder in eine Gallery.
Wenn mir ein User aber Dateien mit mehreren hundert Megabytes übertragen sollte, dann würde ich ihm einfach sagen, dass er es mit einem normalen FTP Client übertragen soll. Die sind für sowas da und können das recht gut.
Kommt darauf an, was genau dein Anwendungsfall ist.
mfg
frafu
Hallo,
ich versuche mal eine Kerze anzuzünden:
Wenn von Upload mit eine Apachen und PHP die Rede sein sollte (da zumindest weiß ich genau, was dort vor sich geht), so ist der Arbeitsspeicher von der ganzen Aktion nur in dem Maße betroffen, das PHP dort für den Prozess geladen wird.
+--------+ +--------+
| Client | - Upload -> | Server |
+--------+ +--------+
|
Upload
|
+--------+
| PHP |-> tmpfile
+--------+
Was passiert also: Die Request-Header werden vom Server empfangen und geparst, dabei stellt dieser fest, daß es sich um ein Anfrage an ein PHP-Script handelt. Der Server macht seine CGI-Schnittstelle klar und läd PHP. Danach reicht er jedes einzeln empfangene Byte direkt an PHP zur Verarbeitung der Anfrage weiter (das kann man sich wie ein Tunnel vorstellen - oder wie ein Firewall). Der Server wird nur noch kontrollieren, ob ein Verbindungstimeout auftritt und ob das Datenvolumen gegen die eigene Konfiguration verstößt (LimitRequestBody).
PHP nimmt den vom Server angelieferten Datenstrom entgegen und parst ihn ebenfalls auf HTTP-Header wie Content-Type (wichtig für boundary - Grenzstring zwischen zwei übertragnen Datein) und Content-Length (u. A.). Dabei legt PHP temporäre Datein (für jedes hochgeladene File eine eigene) in dem vorkonfigurierten Verzeichnis an und schreibt den Datenstrom dort hinein. Dabei ist PHP per Konfiguration gehalten ebenfalls auf die Gesamtgröße zu achten (Konfigurations-Optionen für Datei-Uploads).
Ich müßte es mir noch mal genau ansehen, aber bis auf die einzelnen Buffer (Client->Server, Server->PHP, PHP->FS) füllt dort nichts erhebliches den Arbeitsspeicher.
Gruß aus Berlin!
eddi
Hallo Eddi,
sehr schön erklärt.
Was passiert also: Die Request-Header werden vom Server empfangen und geparst, dabei stellt dieser fest, daß es sich um ein Anfrage an ein PHP-Script handelt. Der Server macht seine CGI-Schnittstelle klar und läd PHP.
auch bei PHP als Modul werden diese empfangenen Bytes weitergereicht und weggeschrieben.
Ich müßte es mir noch mal genau ansehen, aber bis auf die einzelnen Buffer (Client->Server, Server->PHP, PHP->FS) füllt dort nichts erhebliches den Arbeitsspeicher.
Eigentlich nicht nötig, siehe dazu die Ergebnisse meines Praxistests.
Freundliche Grüße
Vinzenz