hotti: Datenübertragung und Datentypen

Beitrag lesen

Hakuna matata!

PS: Lass dich nicht verwirren von den Datentypen ArrayBuffer, Blob, String usw.. Wenn das serverseitig ankommt, sind das nur noch Bytes.

Du wolltest in deinem Codebeispiel ArrayBuffer bestimmt nicht Am Anfang groß schreiben, denn dann erhälst du auf dem Server nur die Zeichenkette: "function ArrayBuffer() { [native code] }"

Selber schuld, wenn Du das Beispiel einfach nur kopierst ;)

Btw., die Idee, mehr Struktur in die Parameterliste zu bringen ist nicht neu und das funktioniert auch mit FormData:

fd.append('addr.name', 'Hesselbach'); fd.append('addr.vname', 'Horst'); fd.append('addr.portrait', file[0]);

in PHP fest verdrahtet als addr[name], addr[vname], addr[portrait] und beachte, dass PHP im Fall addr.name den Punkt leise, still, heimlich und unbemerkt in einen Unterstrich addr_name verwandelt, solltest Du in die Versuchung kommen, was Eigenes bauen zu wollen. Es ist nur so, dass der serverseitige Parser beim enctype="multipart/form-data" einiges zu tun hat, auch dann, wenn Du es nicht selbst programmierst (splitten an der boundary, temporäre Dateien anlegen). Und dann ist POST immer noch ein Request mit Parametern, wass ggf. weitere unliebsame Abhängigkeiten mit sich bringen kann (je nach Framework). Ein PUT ist wesentlich einfacher in der Handhabe, das ist völlig frei von Parametern.

Dass PHP bei einem PUT oder POST (oder anderen beliebigen Request-Methoden) auch im $_GET Array Daten liefert, betrachte ich als eine fehlerhafte Implementierung einschlägiger RFCs betreff HTTP. Und ja, eigene Request Methoden wie FOO, BAR usw. sind durchaus möglich und funktional, es wird jedoch im Allgemeinen davon abgeraten.

MfG