You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment response bodies are parsed as a string:
addBody (data) {
const req = this.peek()
if (req) {
req.body += data
}
}
The issue with this is for example, if responses are gziped or if they have special characters, e.g: ’ –, then the response will be broken because special character information is lost when converting to a string.
However, verifyBody(), expectBody() and onResponse() all offer the body as string, how should we deal with this change?
Cause a breaking change, forcing users to migrate to a Buffer instead of a string
verifyBody(), expectBody() would compare buffers instead of strings
Convert the body to a string before calling verifyBody(), expectBody() and onResponse(), and offer BodyBuffer as a new parameter
Other possibilities?
The text was updated successfully, but these errors were encountered:
Converting the body to a string before comparison offers the advantage of resolving special character and encoding concerns, all while retaining the familiarity of string representation. However, this approach might not be optimal for handling large data due to potential memory inefficiency and the possibility of encountering parsing issues.
At the moment response bodies are parsed as a string:
The issue with this is for example, if responses are gziped or if they have special characters, e.g:
’ –
, then the response will be broken because special character information is lost when converting to a string.However,
verifyBody()
,expectBody()
andonResponse()
all offer the body as string, how should we deal with this change?verifyBody()
,expectBody()
would compare buffers instead of stringsverifyBody()
,expectBody()
andonResponse()
, and offer BodyBuffer as a new parameterThe text was updated successfully, but these errors were encountered: