nicht angemeldet
moin Tom,
Muss das eigentlich immer zwingend urlencoding sein, bei HTTP, oder könnte man auch ein anderes Transfer-Encoding verwenden? War mir doch so, dass jede in die URL-Encoding passende Codierung erlaubt ist, z.B. base64. Der Parser müsste mMn also das Transfer-Encoding auch beachten. Vielleicht kennt ja jemand die passende Stelle in den RFC?
Es gibt mehrere Content-Types für HTTP und Ähnliche für Mail (MIME). Die Festlegung auf einen bestimmten Content-Type ist nur interessant für den Parser, damit die Einzelteile wieder hergestellt werden können. Btw. Content-Transfer-Encoding ist ein Begriff aus der Mail-Welt.
application/x-www-form-urlencoded
und
multipart/form-data
sind die Typen, die derzeit von allen Browsern unterstützt werden und auch am weitesten Verbreitung finden. Ansonsten ist es Wurscht, in welcher Form und wie codiert ein Message-Body aufgebaut ist, im meinem CMS gehe ich daher auch einen eigenen Weg zur Übertragung von Content zum Webserver, vereinfacht gesagt, packe ich die Attribute in den Request-Header und habe im Body nur noch die Datei, also die reine Binary; das bezeichne ich als Single-Content, weil hier kein Multipart vorliegt. http://rolfrost.de/httpcont.html
Auf meinen Seiten findest Du in den Perl-Ordnern weitere Details zu HTTP und auch die (hoffentlich) richtigen Angaben zu den entsprechenden RFCs.
so, ich muss jetzt mal los,
Hotti
MIME ist Müll.