OAuth2: use correct Content-Type as specified in RFC
#2343
Conversation
| @@ -51,7 +51,7 @@ async function _fetch (url, fetchOptions, options) { | |||
| async function _putOrPostOrPatch (method, url, body, headers, options) { | |||
| const fetchOptions = makeFetchOptions(method, headers, options) | |||
| if (body) { | |||
| if (body instanceof FormData) { | |||
| if (body instanceof FormData || body instanceof URLSearchParams) { | |||
| fetchOptions.body = body | |||
There was a problem hiding this comment.
It seems that, by default, since the Content-Type is not set here, the browser (Chromium at least) sets
multipart/form-data; boundary=----WebKitFormBoundaryCBpNkZBPd2t28viKforFormDataapplication/x-www-form-urlencoded; charset=utf-8forURLSearchParams
This is really surprising behavior to me. To me it would make more sense to explicitly specify the two content-types in the two different cases.
There was a problem hiding this comment.
That seems to be documented in https://fetch.spec.whatwg.org/#bodyinit-unions
|
Thanks for opening this PR! Could you explain what problem this solves? E.g. is there a fediverse server that is broken with Pinafore's current approach? |
|
I'm implementing Mastodon API on my own server and that is the issue I spend hours to find why Pinafore doesn't sign in. It's better to make it use standard behavior to help new developers in the future. |
* Token request should use `application/x-www-form-urlencoded`: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3
…son#2343) Co-authored-by: Nolan Lawson <nolan@nolanlawson.com>
application/x-www-form-urlencoded: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3