Elexender: Unbuffered Upload

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.

  1. 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

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. Hi,

      HTTP ist für solche Datenmengen [RR: 500MB] m.E. ungeeignet.

      warum?

      Gruß
      Schlemmi

      1. 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

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. 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

          --
          Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
          Nur selber lernen macht schlau

        2. 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

          1. 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

            --
            Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
            Nur selber lernen macht schlau

          2. 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

            1. ... 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

            2. 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

              --
              Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
              Nur selber lernen macht schlau

              1. 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

                1. 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

                  --
                  Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                  Nur selber lernen macht schlau

                  1. 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.

                  2. 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

                    1. 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

                      --
                      Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                      Nur selber lernen macht schlau

          3. 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

            --
            Man sollte immer wissen was man sagt
             - aber auf keinen Fall alles sagen, was man weiß.
            1. 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

              --
              Achte die Kleinigkeiten, aber liebe das Detail!
              1. 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 übertragen

                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. 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

                --
                Lache, und die Welt wird mit dir lachen.
                Schnarche, und du schläfst allein.
                1. 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

                  --
                  Achte die Kleinigkeiten, aber liebe das Detail!
                  1. 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

                    --
                    Wenn Zeit das Kostbarste ist, was wir haben, dann ist Zeitverschwendung die größte aller Verschwendungen.
                      (Benjamin Franklin, amerikanischer Tüftler und Politiker)
                    1. 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.

                      RFC 2119 -> may

                      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

                      --
                      Achte die Kleinigkeiten, aber liebe das Detail!
                      1. 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.

                        1. 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

                        --
                        Success should be measured not so much by the position that one has reached in life,
                        but by the obstacles one has overcome while trying to succeed.
                        1. 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

                          --
                          Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                          Nur selber lernen macht schlau

                          1. 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

                            --
                            Frei nach Goethe: ... Ich bin ein Teil jener Kraft, die stets das Gute will... ]:þ
                            1. 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

                              --
                              Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                              Nur selber lernen macht schlau

                              1. Re:

                                Das hieße also, das HTTP-Uploads auf jeden Fall 8-Bit transparente Transfersysteme erwarten.

                                PHP jedenfalls ;)

                                Gruß aus Berlin!
                                eddi

                                --
                                Frei nach Goethe: ... Ich bin ein Teil jener Kraft die stets das Gute will... ]:þ
                                1. 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

                                  --
                                  Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
                                  Nur selber lernen macht schlau

                        2. 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

  2. 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.

    1. 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

  3. 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

    --
    Achte die Kleinigkeiten, aber liebe das Detail!
    1. 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