Skip to content

Conversation

@kettanaito
Copy link
Contributor

Changes

Ensures request._bodyInit (the internal representation of a request body) is always set to a [object Object] string representation of a body in case it has a non-stringified JSON body and the Content-Type header stating an expected JSON body.

Why

@kettanaito
Copy link
Contributor Author

kettanaito commented Dec 17, 2020

I'd like to ask for help with adding a test for this. Following the existing tests as examples, I've written this test:

test('converts a non-stringified json body to [object Object] string', function() { return fetch('/request', { method: 'post', headers: { 'content-type': 'application/json' }, body: {stringified: false} }) .then(function(response) { return response.json() }) .then(function(request) { assert.equal(request.data, '[object Object]') }) })

However, request.data is a public request body that gets correctly set to [object Object]. The test doesn't fail when the fix from this pull request is reverted. I can only assume that request.data doesn't equal the request body provided to xhr.send() at the end of a request:

https://github.com/github/fetch/blob/a8aa427de0ed808ff26c0e3eb2e59c122c44488a/fetch.js#L594

Assertions on request._bodyInit fail, that doesn't seem to be public property (dangle implies).

The way I've verified this fix works is by running tests in my reproduction repository that asserts the arguments of the XMLHttpRequest.send call.

} else if (support.searchParams && URLSearchParams.prototype.isPrototypeOf(body)) {
this.headers.set('content-type', 'application/x-www-form-urlencoded;charset=UTF-8')
}
} else if (contentType.includes('json') && typeof this._bodyInit !== 'string') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a reliable JSON request body content-type header check. Would you recommend to provide application/json; charset=UTF-8 instead?

I'm thinking that this behavior should also affect any JSON-like content-type header (i.e. application/hal+json).

@lektor2034
Copy link

thk sir

@kettanaito kettanaito marked this pull request as draft December 17, 2020 08:32
} else if (support.arrayBuffer && (ArrayBuffer.prototype.isPrototypeOf(body) || isArrayBufferView(body))) {
this._bodyArrayBuffer = bufferClone(body)
} else {
this._bodyText = body = Object.prototype.toString.call(body)
Copy link
Contributor Author

@kettanaito kettanaito Dec 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, we can set this._bodyInit to equal this._bodyText in this closure. It fixes the issue, but the solution becomes less deterministic not being connected with the request's content-type. I'm not sure it would be a good idea to always reset the body to its textual counterpart, but I would appreciate some feedback.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this._bodyText

whiteslack
whiteslack approved these changes Dec 19, 2020
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Repository owner deleted a comment from marcin543 Feb 17, 2021
Repository owner deleted a comment from marcin543 Feb 17, 2021
Repository owner deleted a comment from marcin543 Feb 17, 2021
Repository owner deleted a comment from marcin543 Feb 17, 2021
Repository owner deleted a comment Feb 17, 2021
@JakeChampion JakeChampion marked this pull request as ready for review February 17, 2021 17:44
@JakeChampion JakeChampion linked an issue Feb 17, 2021 that may be closed by this pull request
@JakeChampion JakeChampion merged commit 5c6b055 into JakeChampion:master Feb 17, 2021
@kettanaito kettanaito deleted the 856-non-stringified-json-body branch February 17, 2021 20:11
@JakeChampion
Copy link
Owner

This was referenced Jun 6, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 18, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

6 participants