File-Upload: Datei kommt invalide an


#1

Hallo zusammen,

ich habe momentan ein merkwürdiges Phänomen, was ich mir nicht recht erklären kann.

Ich arbeite an einer Funktionalität, womit jemand im Browser eine Datei zum Server uploaden kann, so weit so simpel.
Die Datei kommt auch an, jedoch ist sie auf dem Server größer, als auf dem Client (~3 MB auf dem Client, ~4 MB auf dem Server).

Auf der Clientseite nutze ich JS:


function upload() {
	var reader = new FileReader();
	var file = document.getElementById('uploadInput').files[0];
	var xhr = new XMLHttpRequest();
	
	xhr.open('POST', 'custom?id=upload');
	xhr.overrideMimeType('text/plain; charset=x-user-defined-binary');
	reader.onload = function(evt) {
		xhr.send(evt.target.result);
	};
	reader.readAsBinaryString(file);
}

Wenn ich mir serverseitig den Header des Requests anschaue, sehe ich, dass die Content-Length viel zu groß ist, irgendwas scheint beim Senden also falsch zu laufen.

Ich arbeite typischerweise nicht wirklich im Webumfeld, daher kann es durchaus sein, dass mir irgendwas Banales entgeht.

Grüße,
Shadoka

PS: Im Nachhinein bin ich mir nicht sicher, ob das hier das richtige Unterforum ist. Falls es Anstoß erregt, bitte einfach verschieben :slight_smile:


#2

Tja, leider falscher Bereich. Frag mal Google nach “Java != JavaScript”. [Anmerkung SlaterB: inzwischen verschoben]
Grob geraten: falscher Content-Type. Entweder application/octet-stream oder dieses www-url-encoded - aber text/plain für Binärdaten klingt schon ziemlich falsch.
Btw: Es kann auch am Browser liegen wenn diese File-API nicht korrekt unterstützt wird.


#3

Lösung gefunden.

Vor dem Senden explizit mit Base64 encoden, auf dem Server dann decoden.
“text/plain” funktioniert wunderbar.


#4

Gut, wie JavaScript arbeitet interessiert mich recht wenig - aber von ausgehend das ein “Reader” in der Regel für readable-text ist sollte man statt einem Read schon einen binary-stream nutzen. Oder halt mit (da gabs glaub noch mal sowas wie “www-url-encoded”?) die Arbeit an den Browser delegieren - würd mich da gar nicht selbst drum kümmern.
Auch, wie bereits gesagt: diese File-API muss vom jeweilgen Browser auch korrekt supported werden. Gerade also ältere Browser dürften mit dem Code Probleme haben. Keine Lösung sondern eher ne Krücke - auf sowas sollte man sich nicht verlassen.
Aber naja, ist genau wie JavaScript an sich: irgendwie wie hingekotzt - hat nichts mit sauberer Programmierung zu tun.


#5

Wenn de meenst, Bertha


#6
  1. Nicht in dem Ton.
  2. Sicher dürfte Base64 und dann text/plain funktionieren, dürfte aber weder die Ursache des ursprünglichen Problems sein und ist auch keine all zu schöne Lösung. Erstmal halt der eigentlich unnötige Overheat von im Schnitt 33% und dann auch die Gefahr bei wirklich richtig großen Files (4GB+) die Leistungsfähigkeit der meisten otto-normal-system schlicht zu sprengen (meine Kiste würde zwar noch etwas weiter kommen - aber auch nicht mehr all zu weit). Sinnvolle Lösung sieht anders aus, und zwar eher in Richtung Binärkompression statt Encoding-Overhead.

Aber es ist ja halt auch nur JavaScript und daher an sich schon stark durch die Sandbox limitiert.
Auch mal die generelle Frage: Warum das Rad selbst neu erfinden? Solche AJAX-Upload-Scripts gibts doch genug - Google > copy’n’paste und gib ihm. Da würde ich mir nicht mal die Mühe machen was selbst zu basteln.


#7

Eigene Nase würde ich sagen…

Ich zitiere:


#8

[ot]Es macht aber schon einen Unterschied ob ich eine Sprache an sich für schlecht befinde oder jemanden wegen seiner Meinung persönlich tituliere.[/ot]


#9

Das hast du aber nicht gemacht. Du hast seine Lösung für schlecht befunden und die Sprache gleich mit. Und die “persönliche Titulierung” hört sich für mich eher nach einem Zitat an (welches ich nicht kenne - vllt. Loriot?), welches ausdrücken sollte, dass ihm egal ist, für wie gut du die Lösung befindest.