🐛 Bug Report — fetch response with multiple content-length values yields "internal error"

[jasnell]

When fetch receives a response with multiple content-length headers, the runtime throws an unhelpful "internal error".

Reproduction:

// Node.js script because workers does not let us set the content-length manually:
import { createServer } from 'node:http';
createServer((req, res) => {
  res.writeHead(200, {
    'content-length': [4,5,6],
  });
}).listen(8081);

// Then in workers
const resp = await fetch('http://localhost:8081');

The runtime will log an internal error indicating "invalid Content-Length header value" but does not propagate a useful error up to the user.

Per the spec, fetch should be tolerant of multiple content-length headers without failing and the spec includes an algorithm to extract the content length (https://fetch.spec.whatwg.org/#content-length-header) .. ideally we whould be using that to determine if the content-length is invalid. In the repro example case above, the content-length would be invalid given the inconsistent values but a more useful error should be reported.

In the case there are multiple content-length headers with the same value, e.g. content-length': [5,5,5], the runtime will report this as an invalid content-length and an opaque "internal error". Per the fetch spec, the extracted valid content length here is 5.

Note that per all the specs, having multiple content-length headers with different values is absolutely invalid and should result in an error (it just needs to be a useful one). RFC 9110 indicates that it is acceptable to have multiple content-length headers with the same value but that implementations have latitude to decide how to handle it. The fetch spec algorithm is tolerant of it and will normalize those duplicates away. Other implementations do, in fact, throw an error (like kj). If we are going to continue treating this case as an error rather than follow the fetch spec algorithm, we need to at least make it a useful error rather than a generic "internal error"

This might need to be addressed at the kj-http level more than in the runtime but opening the issue here to track.