From e1c69efe7e8aac2f065404319d4d80e19a2b4f0b Mon Sep 17 00:00:00 2001
From: Lawrence Forooghian <lawrence@forooghian.com>
Date: Tue, 21 May 2024 11:47:20 -0300
Subject: [PATCH] Make FetchRequest not try and parse a 204 response body
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It currently checks for the presence of a Content-Type response header
and if present assumes that trying to parse the response will succeed.

Realtime currently sends a 204 (No Content) with a Content-Type header
from the POST rest.ably.io/push/publish endpoint when using HTTP 1.1
(see REA-1924).

(This bug hasn't been caught by the tests because I guess most of the
time they use HTTP 2 in browsers, and also we don't use FetchRequest in
the tests except briefly in those for the modular variant of the
library. I’ve created #1772 for improving this situation).

The 204 handling approach is copied from that which we already have in
XHRRequest.

Resolves #1771.
---
 src/platform/web/lib/http/request/fetchrequest.ts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/platform/web/lib/http/request/fetchrequest.ts b/src/platform/web/lib/http/request/fetchrequest.ts
index d262ef1af..27dd29bd6 100644
--- a/src/platform/web/lib/http/request/fetchrequest.ts
+++ b/src/platform/web/lib/http/request/fetchrequest.ts
@@ -69,6 +69,10 @@ export default async function fetchRequest(
 
       clearTimeout(timeout!);
 
+      if (res.status == 204) {
+        return { error: null, statusCode: res.status };
+      }
+
       const contentType = res.headers.get('Content-Type');
       let body;
       if (contentType && contentType.indexOf('application/x-msgpack') > -1) {