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
Currently, when sending a request, if any of the operation response body mapper has Stream type, we consider the operation a streaming one, and set request.streamResponseBody to true.
And we use the property request.streamResponseBody to determine the shape of the response after we receive the raw response from http layer.
if the value is true, the body is stored in readableStreamBody (NodeJS.ReadableStream) for Node, or blobBody (Promise) for browser.
if the value is false, the body is stored in bodyAsText (string)
The problem is that some responses of a streaming operation can have non-stream body. One example is the default mapper, which is often used to map error cases, can have text body type.
The fix in PR #13192 uses the response status code to check the response type in the operation spec. However, in core v2, core-https is where we return the response and need to determine the shape of the response, while core-client is where we deal with operation specs. With this separation of responsibilities, we may need a different fix since we don't have access to operation specs in core-https.
The text was updated successfully, but these errors were encountered:
Currently, when sending a request, if any of the operation response body mapper has
Stream
type, we consider the operation a streaming one, and setrequest.streamResponseBody
to true.azure-sdk-for-js/sdk/core/core-http/src/operationSpec.ts
Lines 98 to 111 in 2ae1fb8
And we use the property
request.streamResponseBody
to determine the shape of the response after we receive the raw response from http layer.readableStreamBody
(NodeJS.ReadableStream) for Node, orblobBody
(Promise) for browser.bodyAsText
(string)The problem is that some responses of a streaming operation can have non-stream body. One example is the default mapper, which is often used to map error cases, can have text body type.
The fix in PR #13192 uses the response status code to check the response type in the operation spec. However, in core v2,
core-https
is where we return the response and need to determine the shape of the response, whilecore-client
is where we deal with operation specs. With this separation of responsibilities, we may need a different fix since we don't have access to operation specs incore-https
.The text was updated successfully, but these errors were encountered: