nicht angemeldet
Ajax, custom request-header
0 
MudGuard
0 0 MudGuard
0 0 0 0 0
0
Ajax, custom request-header
Der Martinmein xhr-Objekt kriegt:
xhr.setRequestHeader('Content-Type', 'multipart/c-eav');
am Server kommt an:
Content-Type => multipart/c-eav; charset=UTF-8
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
-
Hi,
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
Evtl. durch Anhängen eines anderen charsets.
cu,
Andreas a/k/a MudGuard-
Hi,
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
Evtl. durch Anhängen eines anderen charsets.
Ne, danke, das soll ja gans weg, das charset= .... ;)
Mein Workaround ist nun
xhr.setRequestHeader('x-Content-Type', 'multipart/c-eav'); und am Server leg ich das dann um if( $ENV{HTTP_X_CONTENT_TYPE} ){ $ENV{CONTENT_TYPE} = $ENV{HTTP_X_CONTENT_TYPE} }Aber Evntl. gipts ja eine andere Methode als setRequestHeader()?
-
Hi,
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
Evtl. durch Anhängen eines anderen charsets.
Ne, danke, das soll ja gans weg, das charset= .... ;)
Was stört Dich eigentlich daran?
cu,
Andreas a/k/a MudGuard-
Hi,
Ne, danke, das soll ja gans weg, das charset= .... ;)
Was stört Dich eigentlich daran?
Dass xhr nicht exakt das macht , was es soll. Ich hab mich schon vor gefühlten 10 Jahren darüber aufgeregt, dass die Angabe eines Charset beim Enctype (daraus wird der Request-Header Content-Type) unsinnig ist. Beim Enctype="multipart/form-data" wird dieser Unsinn offensichtlich und da macht das ja auch keiner.
Und heute, wo ich einen universellen CGI-Parser (war schon längst fällig) entwickle, fällt mir dieser Mist schon wieder auf die Füße. Schließlich fragt der Parser auch den
# Default Enctype by UserAgent $ENV{CONTENT_TYPE} ||= 'application/x-www-form-urlencoded';exakt so ab und falls Charset=xy überhaupt eine Rolle spielt, dann an einer gänzlich anderen Stelle.
Aber was reg ich mich auf, mein Workaround steht ;)
(Und mein neuer Parser macht fünftausend Zeilen CGI.pm überflüssig)
-
Noch ne Blüte aus dem Hause XHR
xhr.setRequestHeader("Content-Type", "application/octet-stream"); daraus wird: Content-Type: application/octet-stream; charset=UTF-8-
xhr.setRequestHeader("Content-Type", "application/octet-stream"); daraus wird: Content-Type: application/octet-stream; charset=UTF-8In bestimmten Fällen ergänzt und/oder verändert der Browser diverse Header-Informationen.
Nachzulesen ist das in der Spezifikation von setRequestHeader(), dort steht in einer Notiz, dass beim Senden Header-Informationen ggf. geändert werden. Folgt man dem Link zur send()-Spezifikationen, stellt man dort unter Punkt 4 fest, dass bei bestimmten Typen des body-Parameters (Blob, BufferSource, FormData, URLSearchParams und USVString) der Content-Type-Header gesetzt wird. Und zwar in einer Weise, die dort auch näher beschrieben ist.
Von hier aus, solltest du dein beschriebenes Verhalten nun selber ergründen und ggf. auch reparieren können.
-
Von hier aus, solltest du dein beschriebenes Verhalten nun selber ergründen und ggf. auch reparieren können.
Verstehe leider nur Banhnhof und sehe da immer noch keinen Weg, dem XHR-Objekt das Anhängen von charset= abzugewöhnen.
-
Tach,
Von hier aus, solltest du dein beschriebenes Verhalten nun selber ergründen und ggf. auch reparieren können.
Verstehe leider nur Banhnhof und sehe da immer noch keinen Weg, dem XHR-Objekt das Anhängen von charset= abzugewöhnen.
im wesentlichen: Setze den korrekten Wert selber; ein leerer oder nicht gesetzter charset-Parameter wird immer in charset=UTF-8 enden.
mfg
Woodfighter-
Hallo,
Verstehe leider nur Banhnhof und sehe da immer noch keinen Weg, dem XHR-Objekt das Anhängen von charset= abzugewöhnen.
im wesentlichen: Setze den korrekten Wert selber; ein leerer oder nicht gesetzter charset-Parameter wird immer in charset=UTF-8 enden.
wenn man im weitesten Sinn textbasierte Informationen verschickt (Formulardaten, XML, JSON, Plaintext), ergibt diese Antwort Sinn.
Was aber ist "der korrekte Wert", wenn man per XHR x-beliebige Binärdaten verschickt? Eine solche Datenwurst hat keine Zeichencodierung, jede Angabe wäre sinnlos oder falsch. Es ist etwa so, als würde man krampfhaft versuchen, einem Text, der vorgelesen wird, eine Schriftfarbe zuzuordnen.
Man kann also IMO nur achselzuckend akzeptieren, dass der Browser da irgendwas einträgt, und die Angabe dann bei der serverseitigen Weiterverarbeitung ignorieren.
So long,
Martin-
Tach,
Was aber ist "der korrekte Wert", wenn man per XHR x-beliebige Binärdaten verschickt?
wenn ich beliebige Binärdaten habe, habe ich z.B. ein Javascript Blob-Object, dessen Type-Attribut passend gesetzt ist und keinen charset-Parameter enthält, dann wird auch kein UTF-8 gesetzt: https://jsfiddle.net/awxtp3ns/ funktioniert in meinem Firefox auch genau so.
mfg
Woodfighter -
hi,
Man kann also IMO nur achselzuckend akzeptieren, dass der Browser da irgendwas einträgt, und die Angabe dann bei der serverseitigen Weiterverarbeitung ignorieren.
Es ist ein schwerwiegender Bruch des Vertrauens, wenn Softwarekomponenten spontan irgendwelche Dinge ändern. Wenn der Entwickler einen Request-Header "Content-Type: application/octet-stream" setzt, dann erwartet er, dass dieser Header genauso auch gesendet wird. Und er wird sich darauf verlassen, dass das genauso auch am Server ankommt: Unverändert und RFC-gemäß, wie denn sonst!!!
-
Es ist ein schwerwiegender Bruch des Vertrauens, wenn Softwarekomponenten spontan irgendwelche Dinge ändern. Wenn der Entwickler einen Request-Header "Content-Type: application/octet-stream" setzt, dann erwartet er, dass dieser Header genauso auch gesendet wird. Und er wird sich darauf verlassen, dass das genauso auch am Server ankommt: Unverändert und RFC-gemäß, wie denn sonst!!!
Und was ist mit allen anderen Header-Feldern, die der Browser für dich sinnvoll ergänzt? Ist das auch ein "schwerwiegender Bruch des Vertrauens"?
-
Es ist ein schwerwiegender Bruch des Vertrauens, wenn Softwarekomponenten spontan irgendwelche Dinge ändern. Wenn der Entwickler einen Request-Header "Content-Type: application/octet-stream" setzt, dann erwartet er, dass dieser Header genauso auch gesendet wird. Und er wird sich darauf verlassen, dass das genauso auch am Server ankommt: Unverändert und RFC-gemäß, wie denn sonst!!! Und was ist mit allen anderen Header-Feldern, die der Browser für dich sinnvoll ergänzt?
'sinnvoll' ist das ausschlaggebende Stichwort ;)
Ist das auch ein "schwerwiegender Bruch des Vertrauens"?
well known behavior
-
-
Es ist ein schwerwiegender Bruch des Vertrauens, wenn Softwarekomponenten spontan irgendwelche Dinge ändern. Wenn der Entwickler einen Request-Header "Content-Type: application/octet-stream" setzt, dann erwartet er, dass dieser Header genauso auch gesendet wird. Und er wird sich darauf verlassen, dass das genauso auch am Server ankommt: Unverändert und RFC-gemäß, wie denn sonst!!!
Die XHR-Schnittstelle wird nicht durch einen RFC spezifiziert, sondern durch den WHATWG Standard. Und sie verhält sich auch konform zu diesem Dokument. Das ist offensichtlich nicht das, was du erwartet hast, das ist ohne Zweifel eine frustrierende Erfahrung. Du kannst den Standard auch für diese (deiner Meinung nach) obskure Semantik kritisieren, aber du kannst hier mit Sicherheit niemanden vorwerfen, entgegen dem Standard dein Vertrauen missbraucht zu haben.
Hast du den Fehler denn inzwischen beheben können?
-
Tach,
Es ist ein schwerwiegender Bruch des Vertrauens, wenn Softwarekomponenten spontan irgendwelche Dinge ändern. Wenn der Entwickler einen Request-Header "Content-Type: application/octet-stream" setzt, dann erwartet er, dass dieser Header genauso auch gesendet wird. Und er wird sich darauf verlassen, dass das genauso auch am Server ankommt: Unverändert und RFC-gemäß, wie denn sonst!!!
ich weiß nicht genau, was du tust, aber das Verhalten in in der Spec exakt definiert. Zeig doch mal deinen kompletten Code und wir können sehen, wo deine Erwartungen von der Realität abweichen.
mfg
Woodfighter
-
-
-
-
-
-
-
-
-
-
-
Tach,
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
warum solltest du das wollen, soweit ich die Spec verstehe, ist UTF-8 das einzig unterstützte Encoding.
mfg
Woodfighter-
Tach,
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
warum solltest du das wollen, soweit ich die Spec verstehe, ist UTF-8 das einzig unterstützte Encoding.
Seit Browser Binaries (ArrayBuffer) unterstützen, ist diese Aussage hinfällig, denn:
- in einem ArrayBuffer können auch anders als UTF-8 kodierte Zeichen übertragen werden,
- ein ArrayBuffer transportiert Rohdaten, auf diesem Level gibt es keine Zeichenkodierung.
Im Übrigen konnte schon immer mit escape() eine 8-Bit-Kodierung (ISO) erzwungen werden. pl
-
Tach,
Seit Browser Binaries (ArrayBuffer) unterstützen, ist diese Aussage hinfällig, denn:
- in einem ArrayBuffer können auch anders als UTF-8 kodierte Zeichen übertragen werden,
- ein ArrayBuffer transportiert Rohdaten, auf diesem Level gibt es keine Zeichenkodierung.
Was haben binäre Daten mit der Zeichenkodierung von Strings zu tun?
Im Übrigen konnte schon immer mit escape() eine 8-Bit-Kodierung (ISO) erzwungen werden. pl
Was hat das mit XMLHttpRequest zu tun?
mfg
Woodfighter-
Was haben binäre Daten mit der Zeichenkodierung von Strings zu tun?
Eben nichts ;)
Deswegen ists ja unsinnig, ein chaset=UTF-8 anzuhängen, was XHR macht.
-
Wie kann ich den xhr-Objekt das Anhängen des charset=UTF-8 abgewöhnen?
warum solltest du das wollen, soweit ich die Spec verstehe
Du hast die Spec von fetch() velinkt, wolltest aber vermutlich auf die von XMLHttpRequest verweisen.
-
Tach,
Du hast die Spec von fetch() velinkt, wolltest aber vermutlich auf die von XMLHttpRequest verweisen.
ah, danke; da bin ich bei der Normalisierung falsch abgebogen und damit ist natürlich auch meine Aussage, dass kein anderes Encoding zulässig ist, falsifiziert.
mfg
Woodfighter
-
-