Two changes to the fetch clients, one of them finishing what v0.6.7 started.

Empty replies, in Chrome too

v0.6.7 stopped the fetch client from parsing a reply with a null body.

That covered the spec, and most runtimes. Chrome is the exception: for a 204 it hands over an empty stream instead of null, so the body looked present, the parse ran, and the call threw again.

Now the client checks the status as well as the body. A null body is still skipped, and so is a 101, 103, 204, 205 or 304, whatever its body looks like. Either way, the call resolves to undefined, by spec.

No more responseMode for non-JSON replies

The client used to read every reply as JSON. An endpoint returning text, a file or form data needed responseMode spelled out on each call.

Now the client reads the content-type and picks for itself:

• JSON, including any +json type -> parsed JSON
• text/*, XML, NDJSON -> a string
• form data -> FormData
• anything else -> a Blob

responseMode still works, and still wins when it is set. It is just no longer needed for the common cases.

One thing to check: a reply with no content-type at all is now read as a Blob, not as JSON. KosmoJS backends always set it, so this only matters for an endpoint that forgets to.