I am trying to use HTTP.get to make a remote api call then try to parse the returned json. However, the returned json object always has a corrupted content. Is it because the api call is https? Can someone please help?
I have put the snippet on meteorpad to demonstrate this issue.
Basically just pick a player then hit the “Add 5 points” link. The console output of result.content is corrupted somehow. If I tried to do JSON.parse(result.content), always get an unexpected token exception. Any help would be appreciated.
The thing is the data returned somehow is a bunch of corrupted characters somehow, maybe because the call is https and the returned json in content is somehow still encrypted?
I’ve checked and confirmed that both https and http return the same data, so it is not an encryption issue.
Regarding gzip, I just checked the docs for the request npm module (which is what the http package uses behind the scenes) and it is supposed to the deflating for you so you don’t actually need to be doing that.
There is also the gzip: false that you can pass along with the npm request parameters option object, and I’ve tried that, but that still gets back a gzipped response so there is something fishy going on here.
Yes, it’s not an encryption issue but gzip issue. I agree that in theory meteor should have returned the gunzipped response since the response header indicate it’s a gzipped content, however, it didn’t work that way. Lucky me. I even tried the gb96:zlib library but have no idea how to make it work. Also tried arunoda’s npm package to load zlib directly, but still no idea how to use zlib library. Any help?
gzip - If true, add an Accept-Encoding header to request compressed content encodings from the server (if not already present) and decode supported content encodings in the response. Note: Automatic decoding of the response content is performed on the body data returned through request (both through the request stream and passed to the callback function) but is not performed on the response stream (available from the response event) which is the unmodified http.IncomingMessage object which may contain compressed data. See example below.
So basically, the response you see should already have been decoded!
Sorry for reviving this, but I stumbled across it when I ran into the same problem and found a solution!
Http.get in it’s options can take npmRequestOptions if you pass an object here with gzip : true then it should decompress your results for you. Worked like a charm for me and I hope it helps you too!