net::ERR_INVALID_RESPONSE (tested)

Chrome shows net::ERR_INVALID_RESPONSE or net::ERR_INVALID_HTTP_RESPONSE when it cannot make sense of what the server sent. We wrote a raw TCP server that sends broken responses on purpose and recorded the exact error each client gave. Most broken responses get a more specific error code, and many load without any error at all. If the server sends nothing at all, see ERR_EMPTY_RESPONSE.

1. The short answer

In our tests, Chromium 153 never returned ERR_INVALID_RESPONSE for a malformed HTTP/1.1 response. When the status line or header block was unreadable it returned ERR_INVALID_HTTP_RESPONSE. Other faults got their own codes: ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH, ERR_INVALID_CHUNKED_ENCODING, ERR_CONTENT_DECODING_FAILED, ERR_CONTENT_LENGTH_MISMATCH and others.

So if you see either name, do not guess. Look at the exact code in DevTools (Network tab, or the console line Failed to load resource: net::...), then find it in the table below. For fetch() the page only gets TypeError: Failed to fetch; the real code is only in the console. See TypeError: Failed to fetch.

2. Our test setup

A Node net.createServer read each request and wrote a fixed string back, then closed the socket. No HTTP library touched the response, so we could send anything:

import net from 'net';
const C = {
  dupcl: 'HTTP/1.1 200 OK\r\nContent-Length: 2\r\nContent-Length: 3\r\n' +
         'Connection: close\r\n\r\nhi!',
  nulvalue: 'HTTP/1.1 200 OK\r\nX-Test: a\0b\r\nContent-Length: 2\r\n\r\nhi',
  // ... 60 cases
};
net.createServer(s => s.on('data', d => {
  const path = String(d).split(' ')[1].slice(1);
  s.end(C[path]);
})).listen(8992, '127.0.0.1');

Chromium loaded each URL as a top-level navigation and as a same-origin fetch(). Both gave the same net error in every failing case. Then we ran the same cases through curl, Node fetch and Python urllib.request.

3. Chromium 153 results

For the body errors (chunked, length, decoding) the navigation committed with status 200 and then failed. The headless page stayed blank and the load event never fired. fetch() rejected.

4. Broken responses Chromium accepted without error

These all loaded with no error in Chromium 153. Other clients were stricter (section 5).

• Status code not a number: HTTP/1.1 abc OK loaded as 200.
• Odd status codes: 0, 99, 600 and 1000 were passed through as-is.
• HTTP/2.0 200 OK, HTTP/3 200 OK, lower-case http/1.1, a missing reason phrase, no space after the version (HTTP/1.1200).
• Space before the colon (X-Test : a), a header line with no colon, a bare CR inside a value, LF-only line endings, folded (obs-fold) header lines.
• Two Content-Length headers with the same value.
• Content-Length: abc, Content-Length: -1 and a 23-digit Content-Length: the body was read until close.
• Content-Length and Transfer-Encoding: chunked together: chunked won and the body was correct.
• Unknown Transfer-Encoding: foo, and unknown Content-Encoding: foo (body shown raw).
• Content-Encoding: gzip with an empty body (Content-Length: 0).
• 500 with an empty body: shown as a normal 500, not a net error.
• A 206 with a garbage or missing Content-Range.

A 204 or 304 that carries a body made the navigation end in net::ERR_ABORTED (no new page). fetch() returned 204 or 304 with an empty body.

5. Same cases in curl, Node fetch and Python

The outer Node error is always TypeError: fetch failed (or terminated if the body broke). Print err.cause to see the real reason.

6. HEAD response with a body

We answered a HEAD request with Content-Length: 2 plus the 2 body bytes, and left the connection open. Chromium fetch, Node fetch and curl all returned 200 with an empty body and no error. None of them reused that connection: the next GET arrived on a new TCP connection (curl -v printed "shutting down connection #0"). So a stray HEAD body does not break clients we tested, but it costs a new connection every time. Fix it anyway: never write a body for HEAD.

7. Fixes

• ERR_INVALID_HTTP_RESPONSE on every page: something is writing bytes before the status line. Typical causes: a debug print or warning that reaches the socket before the headers, a plain-HTTP client talking to a TLS or non-HTTP port, or a proxy pointed at the wrong upstream port. Run curl -v http://host/path; curl will say "Received HTTP/0.9 when not allowed" and you can see the first bytes.
• NUL or control characters in a header: strip them before calling setHeader/header(). Values built from user input or binary data are the usual source. Node's own http module refuses them: res.setHeader('X-T', 'a\0b') threw ERR_INVALID_CHAR "Invalid character in header content" in our test. So this usually comes from hand-built responses or another proxy.
• ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_LENGTH: two layers are each adding a length (app plus a middleware or proxy). Remove one. Details in Content-Length header mismatch.
• Content-Length and Transfer-Encoding together: Chromium tolerated it but Node fetch failed. Send one or the other. See Transfer-Encoding: chunked vs Content-Length.
• ERR_CONTENT_DECODING_FAILED: the header says gzip but the body is not gzip. Usually the body was compressed twice, or not at all, or a proxy decompressed it but kept the header. Check with curl -sS -D - -o body.bin URL and file body.bin. See Content-Encoding gzip vs br in nginx.
• Multiple Location or Content-Disposition: make sure only one code path sets the header. Per the PHP docs (not measured), header() replaces an earlier header of the same name by default; passing false as the second argument adds a second one.
• Strange status codes: Chromium passed 0 and 1000 through, but curl, Node and Python rejected them. Use 100 to 599.

If the connection is cut rather than malformed, see ERR_CONNECTION_RESET. For HTTP/2 framing errors, see ERR_HTTP2_PROTOCOL_ERROR.

Written with AI assistance. Measured on 2026-10-02 with headless Chromium 153.0.8010.12 (Playwright, navigation and fetch), Node.js 24.21.0 fetch, curl 8.14.1 and Python 3.13.5 urllib, against a raw Node net server on 127.0.0.1 that wrote 60 hand-crafted HTTP/1.1 responses byte by byte. PlainHeaders is our extension; curl, Python, Node.js and Chromium are free.