Request-Header Content-Type und XHR
bearbeitet von 1unitedpower> >
> > > Und schon gar nicht den Enctype selbst erraten.
> >
> > Es wird nichts geraten, das Verhalten ist so [spezifiziert](https://fetch.spec.whatwg.org/#concept-bodyinit-extract).
>
> xhr errät aus `x=y` den Content-Type `text/plain; charset=UTF-8` und sendet diesen Header spontan im Request.
Es wird nichts geraten, das Verhalten ist so [spezifiziert](https://fetch.spec.whatwg.org/#concept-bodyinit-extract).
> Ein HTML <form method="POST">, also ohne Angabe des Enctype sendet den Default Content-Type mit demselben Payload `x=y`.
* Wenn ein Formular kein enctype-Attribut hat, wird beim Senden des Formulars implizit `application/x-www-form-urlencoded` als Kodierung gewählt.
* Wenn man `XMLHttpRequest.prototype.send` mit einem `URLSearchParams`-Objekt aufruft, dann wird implizit `application/x-www-form-urlencoded` als Kodierung gewählt.
* Wenn man `XMLHttpRequest.prototype.send` mit einem `USVString` aufruft, dann wird implizit `text/plain` als Kodierung gewählt.
Die `send`-Methode ist überladen. Je nach Typ des Parameters wird eine passende Kodierung gewählt. Welche Kodierung gewählt wird, musst du nicht raten, du kannst es in der Spezifikation nachlesen. Sütestens nachdem du das zweite Mal damit auf die Nase gefallen bist, solltest du das mal in Erwägung ziehen.
> Man könnte also durchaus erwarten, daß sich xhr genauso wie ein Browser verhält, was jedoch definitiv nicht der Fall ist. Siehe Spezifikation (Link weiter oben).
Man könnte auch einfach mal 10 Minuten Handbuch lesen, anstatt ewig im Dunklen zu stochern.
> > Du müsstest dir einfach mal die Mühe machen, den Links zu folgen und die Spezifikationen zu lesen, die dir nahegelegt werden.
>
> Ich denke eher daß sich die Entwickler von xhr und Browser mal damit befassen sollten um hier ein einheitliches Verhalten vorzulegen.
Erstens, lies die Spezifikation bevor du sie kritisierst. Zweitens, kritisier die Spezifikation inhaltlich, nicht ihre Autor*innen.
Request-Header Content-Type und XHR
bearbeitet von 1unitedpower> >
> > > Und schon gar nicht den Enctype selbst erraten.
> >
> > Es wird nichts geraten, das Verhalten ist so [spezifiziert](https://fetch.spec.whatwg.org/#concept-bodyinit-extract).
>
> xhr errät aus `x=y` den Content-Type `text/plain; charset=UTF-8` und sendet diesen Header spontan im Request.
Es wird nichts geraten, das Verhalten ist so [spezifiziert](https://fetch.spec.whatwg.org/#concept-bodyinit-extract).
> Ein HTML <form method="POST">, also ohne Angabe des Enctype sendet den Default Content-Type mit demselben Payload `x=y`.
* Wenn ein Formular kein enctype-Attribut hat, wird beim Senden des Formulars implizit `application/x-www-form-urlencoded` als Kodierung gewählt.
* Wenn man `XMLHttpRequest.prototype.send` mit einem `URLSearchParams`-Objekt aufruft, dann wird implizit `application/x-www-form-urlencoded` als Kodierung gewählt.
* Wenn man `XMLHttpRequest.prototype.send` mit einem `USVString` aufruft, dann wird implizit `text/plain` als Kodierung gewählt.
Die `send`-Methode ist überladen. Je nach Typ des Parameters wird eine passende Kodierung gewählt. Welche Kodierung gewählt wird, musst du nicht raten, du kannst es in der Spezifikation nachlesen. Mindestens nachdem das zweite Mal damit auf die Nase gefallen bist, solltest du das mal in Erwägung ziehen.
> Man könnte also durchaus erwarten, daß sich xhr genauso wie ein Browser verhält, was jedoch definitiv nicht der Fall ist. Siehe Spezifikation (Link weiter oben).
Man könnte auch einfach mal 10 Minuten Handbuch lesen, anstatt ewig im Dunklen zu stochern.
> > Du müsstest dir einfach mal die Mühe machen, den Links zu folgen und die Spezifikationen zu lesen, die dir nahegelegt werden.
>
> Ich denke eher daß sich die Entwickler von xhr und Browser mal damit befassen sollten um hier ein einheitliches Verhalten vorzulegen.
Erstens, lies die Spezifikation bevor du sie kritisierst. Zweitens, kritisier die Spezifikation inhaltlich, nicht ihre Autor*innen.
Request-Header Content-Type und XHR
bearbeitet von 1unitedpower> >
> > > Und schon gar nicht den Enctype selbst erraten.
> >
> > Es wird nichts geraten, das Verhalten ist so [spezifiziert](https://fetch.spec.whatwg.org/#concept-bodyinit-extract).
>
> xhr errät aus `x=y` den Content-Type `text/plain; charset=UTF-8` und sendet diesen Header spontan im Request.
Es wird nichts geraten, das Verhalten ist so [spezifiziert](https://fetch.spec.whatwg.org/#concept-bodyinit-extract).
> Ein HTML <form method="POST">, also ohne Angabe des Enctype sendet den Default Content-Type mit demselben Payload `x=y`.
* Wenn ein Formular kein enctype-Attribut hat, wird beim Senden des Formulars implizit `application/x-www-form-urlencoded` als Kodierung gewählt.
* Wenn man `XMLHttpRequest.prototype.send` mit einem `URLSearchParams`-Objekt aufruft, dann wird implizit `application/x-www-form-urlencoded` als Kodierung gewählt.
> Man könnte also durchaus erwarten, daß sich xhr genauso wie ein Browser verhält, was jedoch definitiv nicht der Fall ist. Siehe Spezifikation (Link weiter oben).
Man könnte auch einfach mal 10 Minuten Handbuch lesen, anstatt ewig im Dunklen zu stochern.
> > Du müsstest dir einfach mal die Mühe machen, den Links zu folgen und die Spezifikationen zu lesen, die dir nahegelegt werden.
>
> Ich denke eher daß sich die Entwickler von xhr und Browser mal damit befassen sollten um hier ein einheitliches Verhalten vorzulegen.
Erstens, lies die Spezifikation bevor du sie kritisierst. Zweitens, kritisier die Spezifikation inhaltlich, nicht ihre Autor*innen.
> Den Default Enctype gibt es ja nicht umsonst und dieser macht ja auch Sinn, zumal Browser ohnehin nur 2 Enctypes unterstützen.
Der Form-Submission-Algorithmus unterstützt nur zwei Kodierungen. An anderen Stellen findest du auch noch mehr Kodierungen. Zum Beispiel beim `XMLHttpRequest`, über den wir hier die ganze Zeit reden.
> Somit ändert xhr den Default eigenmächtig auf text/plain
* Wenn man `XMLHttpRequest.prototype.send` mit einem `USVString` aufruft, dann wird implizit `text/plain` als Kodierung gewählt.
Die `send`-Methode ist überladen. Je nach Typ des Parameters wird eine passende Kodierung gewählt. Welche Kodierung gewählt wird, musst du nicht raten, du kannst es in der Spezifikation nachlesen. Mindestens nachdem das zweite Mal damit auf die Nase gefallen bist, solltest du das mal in Erwägung ziehen.
> und das weicht vom korrekten Verhalten des Browsers ab.
Nein, das ist so spezifiziert.