Closed mgiuca closed 6 years ago
@ewilligers
FormData does not provide an enctype, and always uses multipart/form-data
. I received the impression that application/x-www-form-urlencoded
was a legacy feature that we might not want to propagate.
Discussed offline. While FormData only produces multipart/form-data
, XHR / Fetch are not biased towards multipart/form-data
.
Both the XMLHttpRequest and fetch Request objects take a BodyInit which can be (among other things) a FormData or URLSearchParams, which produce multipart/form-data
and application/x-www-form-urlencoded
, respectively.
So I wouldn't say either of those two are "deprecated" or "legacy".
On the other hand, I don't think we should support encodings other than UTF-8 (due to Encoding spec preface: "Therefore for new protocols and formats, as well as existing formats deployed in new contexts, this specification requires (and defines) the UTF-8 encoding.") or text/plain
(which is not machine-readable and doesn't seem useful).
As of today's update to the spec (#44), targets are allowed to request that they are called with a POST request (which they should if they plan to perform a side-effect, which the semantics of GET does not allow). However, it's specced as always being sent in
multipart/form-data
encoding.This is in contrast to HTML form submission, which defaults
POST
submissions toapplication/x-www-form-urlencoded
but allowsenctype
to override that withmultipart/form-data
.On the one hand, it's just an extra step for developers to remember if they want to send files (which we will support in a future spec update). On the other hand, the way we've specified it here represents an incompatibility with HTML form submission and it seems better to use
application/x-www-form-urlencoded
by default if you aren't submitting a file.