multipart/form-data

[pl]

hi,

Es gibt Kodierungen, wie bswp. PHPs serialize() die machen das wirklich so. Für die Formularkodierung wäre das ungünstig: Wenn große Datenmengen übertragen werden sollen, würde der Upload-Vorgang verzögert werden bis die Datenmenge ermittelt ist. Gerade bei kontinuirlichen Datenströmen, deren Größe man nicht im Voraus kennt, ist das ein Problem, weil man eigentlich schon während des Lesens des Streams parallel Daten hochladen könnte.

Das ist interessant und Grund es so zu machen. Genau dieselbe oder zumindest ähnliche Frage stand im Raum bei der Entwicklung von HTTP/1.0 zu HTTP/1.1, Issue: persistent Connection (Keep-Alive).

Gelöst wurde es über Response Transfer-Encoding: chunked, da sind die Längenangaben den chunks beigefügt. Und auch der Algorithmus zum Deserializieren ist im RFC2616 dokumentiert (nachdem ich von selbst drauf gekommen bin, hab ich das in irgendeiner RFC gelesen *G ).

Nunja, chunked oder Content-Length, multipart/form-data in meinen UniParser mit aufzunehmen, Ehrensache und ohne das Monster CGI.pm ;)

Die nächsten Tage => Neuer Content-Type: application/rpc-eav und evntl noch /cms-eav. Proprietär aber /rpc-eav liefert nach dem Parsen exakt dasselbe wie /xml+rpc nur dass die Daten anders verpackt sind. Ich hab ne ganze Menge an Webservices, RPC-Zeugs und Content-Management per HTTTP zu machen, das ist z.T. noch in diskreten .cgi-Dateien verstreut. Mit meinem neuen UniParser wird das alles Eins und läuft über dasselbe Framework was auch ganz normal HTML oder sonstigen Content ausliefert.

Über die Tragweite meines neuen Parsers bin ich mir gar noch nicht so richtig klargeworden, eigentlich wäre das ein riesen Grund zum Feiern, allein schon die Idee..... pl