w3c / web-share-target

Web API proposal for receiving shared data
https://w3c.github.io/web-share-target/
Other
191 stars 20 forks source link

Consider adding an "enctype" member to ShareTarget (so POST targets can accept application/x-www-form-urlencoded) #47

Closed mgiuca closed 6 years ago

mgiuca commented 6 years ago

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 to application/x-www-form-urlencoded but allows enctype to override that with multipart/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.

mgiuca commented 6 years ago

@ewilligers

ewilligers commented 6 years ago

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.

mgiuca commented 6 years ago

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).