This code is pretty much the same in both places, this should make the maintenance easier.

Fixes https://github.com/ipfs/go-ipfs-http-client/issues/5, Depends on https://github.com/ipfs/go-ipfs-http-client/pull/18

cc @postables. Does this break anything?

@magik6k could you test this against tools like ipget? If that still works, I'm fine going ahead with this.

Finally noticed the cc and got around to testing some of the tools I have that use go-ipfs-api. This change breaks some functions of tools I have written that have non-standard ways of using go-ipfs-api.

I don't really see this as an issue, certainly not something worth trying to prevent this PR from being merged simply because:

• It's non standard code that isn't part of upstream (ipfs/go-ipfs-api) which should be expected to break at some point in time because its not officially part of the codebase
• I'm probably the only one, or only one of a few people using these non-standard methods
• The benefits of this PR vastly outweigh any perceived benefits from unofficial code

If desired I can follow this post up with examples of the non-standard functions I'm using. For clarification, all the errors that I'm getting are failed to connect to ipfs node at '<insert-ip-address>': operation not supported

tl;dr

LGTM but it may effect some people using this library in ways that aren't part of ipfs/go-ipfs-api however this is probably a non-issue

@postables some examples would definitely be helpful.