Skip to content
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

Investigate only piping the payload after a connection is established #222

Closed
geek opened this issue Jul 6, 2018 · 2 comments · Fixed by #223
Closed

Investigate only piping the payload after a connection is established #222

geek opened this issue Jul 6, 2018 · 2 comments · Fixed by #223
Labels
bug Bug or defect
Milestone

Comments

@geek
Copy link
Member

geek commented Jul 6, 2018

Relates to

wreck/lib/index.js

Lines 303 to 322 in 576ce9d

if (payloadSupported) {
if (options.payload instanceof Stream) {
let stream = options.payload;
if (redirects) {
const collector = new Tap();
collector.once('finish', () => {
shadow = collector.collect();
});
stream = options.payload.pipe(collector);
}
stream.pipe(req);
return req;
}
req.write(options.payload);
}

@ggoodman
Copy link
Contributor

ggoodman commented Jul 6, 2018

When passing a readable stream as options.payload, the readable stream will be piped to the ClientRequest before a socket connection is established. That causes the stream to be put into the flowing mode meaning that the stream cannot be re-used in the event that no socket connection can be established.

Our work-around has been to pass a stream.PassThrough instance as options.payload and then to pipe the actual payload into the pass-through stream once a socket connection is established ('connect' event on the socket).

ggoodman added a commit to ggoodman/wreck that referenced this issue Jul 23, 2018
@geek geek closed this as completed in #223 Jul 24, 2018
@geek geek added the bug Bug or defect label Jul 24, 2018
@geek geek added this to the 14.0.3 milestone Jul 24, 2018
@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Bug or defect
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants