langjt/node-http-proxy-json

"Unexpected token in JSON at position 0" error

Closed this issue · 2 comments

Hi again!

In the course of using this module in a project, I ran into a curious situation. On certain requests, the module will raise an unrecoverable error when attempting to parse the response as JSON. The full stack trace is below.

Have you ever encountered this in your use of the module? How did you handle it? The responses we're receiving from the upstream source are valid JSON, which makes it tricky to determine the source of this error.

Any assistance you can provide is greatly appreciated!

Brandon

JSON.parse error: SyntaxError: Unexpected token � in JSON at position 0
    at Object.parse (native)
    at ServerResponse.res.end (/Users/username/project/node_modules/node-http-proxy-json/index.js:101:25)
    at IncomingMessage.onend (_stream_readable.js:511:10)
    at IncomingMessage.g (events.js:291:16)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
buffer.js:257
  throw new TypeError(kFromErrorMsg);
  ^

TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
    at fromObject (buffer.js:257:9)
    at Function.Buffer.from (buffer.js:97:10)
    at new Buffer (buffer.js:76:17)
    at ServerResponse.res.end (/Users/username/project/node_modules/node-http-proxy-json/index.js:112:16)
    at IncomingMessage.onend (_stream_readable.js:511:10)
    at IncomingMessage.g (events.js:291:16)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)```

@skylineproject Whether the Content-Encoding is rightly set. Confirm your server compression format, currently only supports gzip、deflate and uncompressed.
Is likely to be because the Content-Encoding is empty, but the actual content is compressed by some compression format.

Ah, understood – thanks so much! As you might've surmised, I'm dealing with a situation where the upstream content encoding is ambiguous and often incorrect. Thanks for your assistance!