nicht angemeldet
Mahlzeit;
Dabei handelt es sich im obigen Fall auch um das Content-Encoding, nicht um das Content-Transfer-Encoding. Das bildet eine zweite "Kodierungs-Hülle".
Nochne Anmerkung: Der Header "Content-Type" hat im Request eine völlig andere Bedeutung als in einer Response. Ebenso ist die Charset-Angabe im Request unnötig, bisher hat das auch kein Browser gemacht, der neue FF macht das jedoch (hat mich schonmal Nerven gekostet).
Der Header "Content-Transfer-Encoding" spielt nur bei Mail eine Rolle, nicht jedoch bei HTTP. Bei HTTP ist "Content-Type" nur eine Deklaration für den Parser, beispielsweise steht bei
Content-Type: multipart/form-data; boundary=boundary_string
hintendran die Zeichenkette der boundary, damit der Parser serverseitig "weiß" wie die Komponenten getrennt sind. Bei multipart/form-data enthält eine Einzelkomponente die Angabe des inhaltsbezogenen "Content-Type" z.B. image/gif. Die Doppeldeutigkeit des Headers "Content-Type" ergibt sich aus der Tatsache, dass es eben in einem Request verschiedene Möglichkeiten gibt, wie Komponenten im Mesg-Body eingebaut sind.
Anders ists bei einer Response, hier liegt i.d.R. nur _eine_ Komponente vor, und dementsprechend bezieht sich die Angabe "Content-Type" direkt auf den Inhalt. Z.B.
Content-Type: text/html; charset=UTF-8
<...hier kommt dann "nur" HTML und nüschd Anderes...>
Selbstverständlich kannst Du auch eine Multipart-Response senden, die Frage ist dann nur, wie der UserAgent damit zurechtkommt. Ich benutze für meine Ajax-Responsen den Content-Type: application/x-www-urlencoded und kann damit vorzüglich meine Objekte und Arrays serialisiert übertragen. Das Parsen einer solchen Response im DOM funktioniert genauso wie das serverseitige Parsen eines Requests, ich habe damit ein einheitliches Encoding, einheitliche Schnittstellen und bin außerordentlich flexibel damit.
Bissl was zm Lesen noch http://rolfrost/httproto.html
Horst Hobbit
Jetzn Kakao...