content-type parsing is performed even if a `text` response type is explicitly requested, causing an unmanageable error about gaxios HOT 3 CLOSED

Please see: #554 I believe this should resolve the issue you are facing with the missing text content handling.

from gaxios.

Thanks, I'll test it to ensure it works correctly in my case.

Looking at the code, I tried to find remaining potential places where the response is attempted to be parsed as JSON, in which gaxios would produce an error when the JSON fails to parse:

• If the user doesn't specify a response type, getResponseDataFromContentType may throw an error if the server reports a content-type of application/json but the response fails to parse as JSON.
• On the other hand, due to the try { ... } catch { /* continue */} in getResponseData, if the user explicitly requests a 'json' response type, and the parsing fails, they will not get an error, even if the server's returned content-type was actually application/json (the content-type is not checked in this case). That looks somewhat inconsistent, since I would assume that the expectation here would be stronger, since the both the user has explicitly indicated they expect a JSON response, and the server itself indicated that its content-type was supposed to be JSON (to clarify - I'm not necessarily suggesting having it error in this case is a good or bad idea, just mentioning this scenario for comparison).
• I also noticed, in common.ts, that when constructing a GaxiosError, translateData may fail to parse the response as JSON in the cases where the user requested 'json', 'arraybuffer' or 'blob'. So it would fail to create a new GaxiosError object. Usually when constructing an Error object, it is undesirable to have the Error construction itself throw an Error. This isn't completely related to the original issue, but I noticed it.

from gaxios.

Regarding 1 & 2. I will put a fix in place to make it consistent behavior, thanks for the heads up! Let me take a closer look at 3.

from gaxios.