Demo: JavaScript und Binärdateien, Multimedia

[Der Martin]

Hallo,

Streaming heißt für mich, dass die übermittelten Daten direkt verarbeitet werden (...) (Ansicht deckt sich nur), wenn das Speichern als Datei der eigentliche Zweck der Operation ist.

Ja, so hatte ich das aufgefasst. Upload auf einen Server zum Zweck der Multimedia-Wiedergabe ist wohl eher ein Sonderfall.

natürlich, aber ich hatte das nicht auf Uploads beschränkt gemeint.

Ich denke, unsere Ansichten decken sich.

Zumindest in diesem Punkt. ;-)

In PHP ist das bei multipart/form-data so gelöst, dass anhängende Uploads vom Server automatisch als Temp-Dateien gespeichert und nicht im RAM gehalten werden. Allerdings deute ich die Hinweise auf die RAM-Limitierung in der PHP-Doku so, dass auch PHP eine einzelne Datei erstmal im RAM montiert bevor sie in den TEMP-Ordner kommt.

Woraus liest du das ab? AFAIK gibt es für PHP generell ein einstellbares Speicherlimit, das die verfügbare RAM-Menge pro Script begrenzt. Das hat aber mit File-Uploads nichts zu tun. Und dann gibt es ein Größenlimit für Uploads, das aber IMO nicht darauf schließen lässt, dass die Daten zunächst im RAM gehalten werden.

Einmal diese grundsätzlichen Infos zum Upload per POST. Das $_FILES Array enthält einen Temp-Namen, also gibt's auch eine Temp-Datei :)

Ja, das war mir klar, und das ist ja auch dokumentiert. Die allgemeinen Infos, die du gefunden hast, sind allerdings schwammig. Ich finde beispielsweise keinen Hinweis darauf, was denn genau passiert, wenn MAX_FILE_SIZE tatsächlich überschritten wird.
Aber dass eine solche Überprüfung überhaupt stattfindet, heißt doch zwingend, dass die Datei(en) komplett übertragen werden, bevor das PHP-Script losrennt. Denn vorher ist die Dateigröße ja noch nicht bekannt.

Dass PHP die Datei im Speicher montiert bevor es sie schreibt schließe ich hieraus. Da steht, dass das Limit der Dateigröße 2 MB beträgt und man bei Erhöhen der upload_max_filesize eventuell das memory_limit anpassen muss.

Der mehrfache Hinweis auf memory_limit deutet tatsächlich stark darauf hin.

Bei unbekannten Content-Typen sagt das PHP Handbuch, dass es auf die SAPI-Implementierung ankäme, ob die POST Daten gepuffert würden oder nicht.

Schade, dass du die Stelle nicht verlinkt hast. Ich vermute nämlich, du hast das missverstanden.

Hier, die Note zu php://input.

Hmm. Das verstehe ich so, dass diese Anmerkung nur vor PHP-Versionen vor 5.6 gilt, und dass bei diesen älteren Versionen die Daten von POST-Requests gespeichert wurden und daher mehrfaches, unabhängiges Öffnen von php://input möglich ist, bei anderen Request-Methoden jedoch nicht. Für PHP ab 5.6 gibt es dazu anscheinend nichts mehr zu beachten, php://input unterstützt da sogar seek-Operationen - was auch wieder bedeutet, dass die Daten vorher gespeichert wurden.

Ungepuffert würde bedeuten: sie bleiben als IP Pakete auf der Leitung (und der Client wartet), bis das PHP losläuft und sie liest.

Nein, das läuft so nicht. AFAIK nimmt der Webserver den vollständigen POST-Request entgegen, bevor er den PHP-Prozess überhaupt startet.

Ok, jetzt drehen wir den Bratspieß mal um. Kannst Du dafür eine Quelle angeben? :)

Nein, das ist reine logische Schlussfolgerung (siehe oben).

So long,
 Martin