It seems browsers (at least Chrome) are smart enough to duplicate the response stream if users:
clone the response.
- resolve the original response completely.
- and then resolve the cloned response.
Per Fetch Spec's clone definition, we should tee the stream at step 1, and tee is defined in Stream Spec. node-fetch does this already.
Problem: we don't know the response body size beforehand. So when user clone, they still risk running into backpressure issue; as on step 2, when data starts flowing for both the original and the cloned stream, and because we are not reading from cloned stream at the time, its internal buffer will fill up, eventually, causing both stream to pause and hence what we called backpressure.
It seems Chrome has a higher default buffer size than Node.js, so when users approach this problem with isomorphism, they run into issues where request works on client-side, but failed on server-side.
There are on-going discussion at whatwg/streams#401 and I am asking this again just to be sure whatwg/streams#506
It seems browsers (at least Chrome) are smart enough to duplicate the response stream if users:
clonethe response.Per Fetch Spec's clone definition, we should
teethe stream at step 1, andteeis defined in Stream Spec.node-fetchdoes this already.Problem: we don't know the response body size beforehand. So when user
clone, they still risk running into backpressure issue; as on step 2, when data starts flowing for both the original and the cloned stream, and because we are not reading from cloned stream at the time, its internal buffer will fill up, eventually, causing both stream to pause and hence what we called backpressure.It seems Chrome has a higher default buffer size than Node.js, so when users approach this problem with isomorphism, they run into issues where request works on client-side, but failed on server-side.
There are on-going discussion at whatwg/streams#401 and I am asking this again just to be sure whatwg/streams#506