---
url: /blog/2026/v0.6.8.md
description: >-
  v0.6.8 finishes the empty-reply fix from v0.6.7 for Chrome, and fetch clients
  now pick how to read a reply from its content type.
---

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.