File Upload und Sicherheit

[dedlfix]

Tach!

Die Gesamtgröße spielt keine Rolle mehr, wenn jede Datei mit ihrem eigenem Request verarbeitet wird.

Diesen Satz weiss ich nicht so richtig zu deuten. Klar, für 10 HTTP-Uploads á 100MB werden die Konfigurationen für 100MB vorgenommen werden müssen und nicht für 10*100MB.

Wenn dir das schon klar ist, dann ist gut. Du hattest nur drei Postings vorher die Rechnung aufgemacht 10 × 100MB = 1GB. Darauf bezog ich mich.

Richtig, hatte ich auch. Weil ich bis vorhatte, ein Formular mit 10 input[type=file] zu bauen.

Also doch. Bei den geplanten Dateigrößen würde ich keinesfalls einen Mehrfach-Upload implementieren wollen. Schon eine Datei dieser Größenordnung sprengt ja die üblichen Limits und man muss die Konfigurationswerte aufbohren. Sich mehr Probleme als nötig aufzuhalsen, ist nicht empfehlenswert.

Auf Client-Seite muss man ja auf keinen Komfort verzichten. Da gibt es genügend Komponenten, zum Beispiel das von Felix Riesterer gern empfohlene Plupload. Das schickt die Dateien nacheinander über die Leitung, jede in einem eigenen Request.

Damit wäre der Client-Teil erledigt und der erste Teil der Serverseite, wenn man das in der Dokumentation gezeigte Minimalscript für PHP nimmt. Damit kannst du erstmal das Verhalten bei verschiedenen Dateigrößen testen.

1. Die Uploads in einzelne Requests aufteilen

Mit der erwähnten Komponente sollte das ganz einfach werden.

2. Die Weiterverarbeitung der Files nach dem Upload einen Hintergrundprozess machen lassen

Damit wird die Aufgabe komplexer aber beide klingen vernünftig. Nur warum?

Das Wegschieben per FTP musst du ja sowieso implementieren. Dem Teil sollte es egal sein, wo die Datei herkommt. Das kann man als Parameter übergeben. Für den Anfang ist es eben der temporäre Upload-Name, später denn - vielleicht - die Datei aus der Zwischenlagerung.

1. Die Zeit, die der User warten muss, bis all seine Daten übertragen wurden unterscheidet sich ja nicht wesentlich dadurch, wenn für jedes input[type=file] ein eigener Request gestartet wird statt in eine Request alle Files auf einmal zu übertragen.

Die clientseitige Komponente zeigt auf jeden Fall einen Fortschritt an. Ich weiß gar nicht, wie das bei einem nackigem input type=file in den Bowsern aussieht.

Und klar, die Laufzeit ist stark abhängig vom Uplink des Anwenders.

2. Wenn die Files nach dem Upload und einer Validierung mit php per ftp verschoben werden, ist es zunächst mal so, dass der User abwarten muss, bis php damit fertig ist. Deshalb hatte ich danach gesucht, ob sich das umgehen lässt und ignore_user_abort(true) gefunden. Keine Ahnung, ob es damit geht, ob das irgendwelche Problem nach sich zieht.

Da kann ich dir nicht mit Erfahrung dienen.

Obwohl ich nicht genau sagen kann warum, zweifle ich langsam an der Aufgabe an sich und ich weiss nicht mal warum ;)

Einfach mal klein starten. Erstmal kleine Dateien hochladen, ohne großartige serverseitige Verarbeitung. Dann die großen Boliden. Es ist dabei durchaus auch sinnvoll, das mit den normalen Konfigurationswerten zu probieren, damit man weiß, wie das aussieht, wenn man ans Limit stößt. Dann weiter mit dem Konfigurieren des Webservers für die großen Dinger. Nun das FTP-Verschieben direkt im Script testen und wenn das akzeptabel schnell ist, dann war's das schon. Bei Bedarf baust du noch die Cronjob-Variante dazu, aber zumindest hast du jetzt schon ein lauffähiges System.

dedlfix.