Im dritten Teil möchte ich zunächst einen Blick hinter die Haube des Flash-Uploads werfen und dabei auf ein grundsätzliches Problem mit dem Upload eingehen.
Bei der Recherche zu dem Thema Flash-Upload findet man in unzähligen Blogs immer wieder Kommentare von Benutzern, die über Fehlermeldungen klagen und diese nicht zuordnen können. Die zuletzt vorgestellten Fehlerabfragen helfen ein wenig, wenn es mit dem Upload einmal nicht funktionieren sollte. Bekommt man bspw. einen HTTP-Error 403 (Forbidden) hat man einen ersten Anhaltspunkt für die Ursache. Besonders aussagekräftig sind diese Fehlermeldungen jedoch nicht …
Packet Sniffer
Über einen Packet-Sniffer ist es möglich den Datentransfer etwas genauer unter die Lupe zu nehmen und dabei wichtige Informationen über die Fehlerquelle zu sammeln.
Ich habe in diesem Zusammenhang verschiedene freie Packetsniffer ausprobiert. Meine Empfehlungen für Windowsnutzer sind der Packetyzer von Network Chemistry und die IP-Tools von Erwan L. Sehr einfach in der Bedienung und übersichtlich ist auch der Charles Debugging Proxy. Den Tip bekam ich von Marcel Fahle.
[Update] Fiddler, HTTP Debugging Proxy, von Microsoft (benötigt .NET Framework).
Was genau passiert beim Flash-Upload eigentlich?
Als erstes sendet Flash einen 0-Byte großen HTTP-Request an das serverseitige Script. Der Server antwortet (Response) mit einem HTTP 200 (ok). Anscheinend testet Flash mit diesem Packet zunächst, ob das Script existiert und für einen HTTP-Request bereit ist. Diese Vorgehensweise ist unüblich, bei einem Upload über ein HTML-Formular, sendet der Client (Browser) die Daten direkt, siehe Screenshot:
Nachdem Flash den HTTP-Respone erhalten hat, sendet es dann die eigentlichen Daten an das Script:
Diese Vorgehensweise kann unter Umständen dazu führen, dass der zweite Request mit einem negativen Response (HTTP-Error 403) beantwortet wird und der Upload scheitert. Das Problem trat bei mir auf, als ich versuchte einen Flash-Upload auf einem Apache-Server, welcher ein speziellen „Security Mod“ benutzte um PHP-Exploits abzuwehren, einzurichten.
Weiterhin gibt es in diesem Zusammenhang Probleme mit Ruby on Rails, hier nachzulesen.
Erweiterung der Upload-Anwendungen: Fortschrittanzeige und Dateiinformationen
Das Objekt fileRef der FileReference Klasse stellt vier Eigenschaften „name“, „size“, „modificationDate“ und „creationDate“ zur Verfügung. Die Daten sollen nach der Auswahl der Datei angezeigt werden. Dazu wird die Klasse, wie folgt geändert:
...
// Textfelder
private var myFile_txt:TextField;
private var fileSize_txt:TextField;
private var creationDate_txt:TextField;
private var modDate_txt:TextField;
...
public function MUploader(mc:MovieClip) {
...
// Textfelder
myFile_txt = target_mc.myFile_txt;
fileSize_txt = target_mc.fileSize_txt;
status_txt = target_mc.status_txt;
creationDate_txt = target_mc.creationDate_txt;
modDate_txt = target_mc.modDate_txt;
...
}
...
private function fileSelected():Void {
updateFileInfo();
}
...
private function updateFileInfo():Void {
myFile_txt.text = fileRef.name;
var fileSize:String = String(fileRef.size/1024);
var firstPos:Number = fileSize.indexOf(".");
fileSize_txt.text = fileSize.substr(0,firstPos+2);
creationDate_txt.text = String(fileRef.creationDate);
modDate_txt.text = String(fileRef.modificationDate);
}
}
Mithilfe der Ereignis-Prozedur onProgress lässt sich der Fortschritt während des Uploadvorgangs berechnen. Die Klasse wird folgendermaßen modifiziert:
class MUploader {
...
private var progressDisplay_mc:MovieClip;
public function MUploader(mc:MovieClip) {
...
progressDisplay_mc = target_mc.progressDisplay_mc;
progressDisplay_mc._visible = false;
...
fileRefListener.onProgress = Delegate.createPacked(this,showProgress);
...
}
private function showProgress(fileRef:FileReference,bytesLoaded:Number, bytesTotal:Number):Void {
progressDisplay_mc._visible = true;
var prozent:Number = Math.round((bytesLoaded/bytesTotal)*100);
progressDisplay_mc.progressBar_mc._xscale = prozent;
}
...
private function fileUploadCompleted():Void {
...
progressDisplay_mc._visible = false;
}
}