JSON Serialization error on 204 application/json with empty body

[superr-fluous]

Version: 2.0.2
Browser: Chrome (Brave)

Hi! I am currently facing an issue when my server responds with a 204 No Content while simultaneously sending content-type: application/json, which results in "Unexpected end of JSON input" error.

From #732 my understanding is that Ky is supposed to shortcut on 204 and empty responses to avoid calling unnecessary json decoding. However, since that issue and subsequent PR, some changes were introduced and now empty JSON responses are handled with JSON.parse (if no schema is passed):

const response = await result;

if (type !== 'json') {
  return ky.#raceBodyRead(async () => response[type](), response);
}

const text = await ky.#raceBodyRead(async () => response.text(), response) as string;
const request = ky.#getResponseRequest(response);
return ky.#raceWithTotalTimeout(async () => {
  if (text === '') {
    if (schema !== undefined) {
      return validateJsonWithSchema(undefined, schema);
    }
    // if type === 'json` and text === '', which is always going to throw an Error
    return JSON.parse(text);
  }

I believe that at the end there should be return undefined (null, "" or whatever).
OR
a check for custom parseJson which would handle the case.

[sholladay]

For a long time, Ky treated a 204 response as a successful, albeit empty response and if you called ky().json(), we represented "empty" by returning an empty string. My thinking was that HTTP is just text, it's a valid value you could receive from native response.json() or JSON.parse(), and an empty string is more useful than a parse error, while still being a faithful representation of what was sent over the wire and the intent of 2xx responses to be successful.

Personally, I stand by that philosophy. However, it was clear that not everyone agreed. See previous discussions of 204 behavior. In particular, #732. You'll find that opinions about what to do for 204 responses are all over the place.

In Ky v2, we changed the behavior to match fetch(), such that ky().json() with a 204 response results in a "Unexpected end of JSON input" parse error. You can see that this is the expected behavior in the tests. Whether this was the right choice, I don't know. It's certainly my least favorite change in v2.

The good news is it's fairly easy to catch and detect "Unexpected end of input". Or you can call ky() instead of ky().json() and handle the parsing yourself, based on the status code. So there are workarounds.

[superr-fluous]

Thanks for the detailed answer!
I do agree that this is not critical at all, however I do strongly feel that Ky should check for custom parseJson since, as user, I would expect that all JSON decoding is delegated to my custom handler.
Actually, at first, I did try to handle the case with custom parseJson function that checked for "empty" values and the fact that it doesn't work here is kind of inconvenient, because now I feel like I need to make a custom wrapper around ky() to specifically handle this case.

[sholladay]

I think the idea was that parseJson isn't called because, strictly speaking, JSON wasn't received.

But I agree with you. If JSON.parse is called, which it is, then parseJson should be called instead, if it is provided.

I'll work on this.