-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement pause
option for resolving with stream
#16
base: master
Are you sure you want to change the base?
Conversation
- Initialize options at the beginning of init - Extract the code that resolves / rejects the promise into separate functions
5 similar comments
Does this look good to you? If it does, I'll add tests |
Thanks for finally submitting a PR - I never got around to it since i had my custom resolve-stream-from-promise wrapper around request and never needed it anywhere else, and I'm not using The changes I can see being needed are documentation, and as this option means that the stream is being resolved, personally, i'd call the option Also, on errors, in my old proof of concept, (and what I did in the previously-mentioned wrapper) is to read the body on error, rather than completely discarding it. IMO, in |
See request/request-promise#90. The particular implementation details are:
transform
andresolveWithFullResponse
are always ignored.simple = true
and the response is a 404), so the response cannot be streamed in that case. This is a limitation, but 99% of the time users aren't interested in the error body, so that'd be a memory leak unless they make surestream.resume()
is called on rejections. And if you really need to stream error responses, you can usesimple = false
.Proposed documentation and examples for the option:
pause = false
which is a boolean that when set, the promise will be resolved with the raw response stream (http.IncomingMessage
) before the body arrives (e.g. when theresponse
event fires). ImpliesresolveWithFullResponse = true
andtransform = null
..pipe()
and others resume it automatically, otherwise you may need to call.resume()
manually, even if you do nothing else with the stream.The implementation is in the second commit, the first is just a refactor to prepare for the changes.