update get-dagNode for buffers

[nginnever]

This adds a check for the response from the go/js daemons to see if data is sending a stream or a buffer. This is needed for PR

@noffle for CR

[hackergrrl]

Could we just update + push a new version of js-ipfs that returns streams instead of buffers, and avoid this branching & complexity altogether?

[nginnever]

I thought about doing that but would need to see if any other modules / tests rely on object/data returning a buffer not a stream.

I agree that it would be nice to have this fix less abstracted away but the error is in a pretty specific use case of the js-ipfs daemon handling requests for add command only (via js-ipfs-api).

Would it be more work than it is worth to put the fix in the core just for one use case of one command?

[hackergrrl]

It's a valid stop-gap that maintains backwards compatibility. My primary concern is having core consistently returning the same thing on js-ipfs and go-ipfs (streams, that is).

[daviddias]

Thank you @nginnever, good catch. Seems that this is due that go-ipfs sometimes likes to send a stream instead (x-stream) and js-ipfs-api request-api.js module catches that and exposes it as a stream, but sometimes, if the x-stream header is not set, it actually buffers the whole thing.

Getting the data from an object should not come as a stream, that seems like an inconsistency from go-ipfs //cc @whyrusleeping

@nginnever could you make sure this is covered by tests. Can you get the problem reproduced easily? It would help to debug in go-ipfs.

[daviddias]

I'm merging this one. It is hard to make a test that easily reproduces the issue, because it depends on how go-ipfs feels. Current tests pass and the change is small enough and solid.

Thank you @nginnever :)