content-length missing when set on header response

[vlovich]

If the user sets a content length in response to a HEAD request that content-length is sent to the eyeball. Under miniflare the content-length is stripped

[mrbbot]

Hey! 👋 I'm guessing this is coming from here:

miniflare/packages/http-server/src/index.ts

Lines 179 to 202 in ae2349c

	if (headers["content-encoding"] && response.encodeBody === "auto") {
	// Content-Length will be wrong as it's for the decoded length
	delete headers["content-length"];
	// Reverse of https://github.com/nodejs/undici/blob/48d9578f431cbbd6e74f77455ba92184f57096cf/lib/fetch/index.js#L1660
	const codings = headers["content-encoding"]
	.toString()
	.toLowerCase()
	.split(",")
	.map((x) => x.trim());
	for (const coding of codings) {
	if (/(x-)?gzip/.test(coding)) {
	encoders.push(zlib.createGzip());
	} else if (/(x-)?deflate/.test(coding)) {
	encoders.push(zlib.createDeflate());
	} else if (coding === "br") {
	encoders.push(zlib.createBrotliCompress());
	} else {
	// Unknown encoding, don't do any encoding at all
	log?.warn(`Unknown encoding \"${coding}\", sending plain response...`);
	encoders.length = 0;
	break;
	}
	}
	}

This header probably shouldn't be deleted unless some encoders are set, but even then, I think it's still the right thing to do with encodeBody set to auto? Let me know if I'm misunderstanding something.

[vlovich]

HEAD responses don't have a body so not sure how encodeBody is playing a role. Also, this behavior is not consistent with behavior in the runtime I think. On the other hand, it could be specific to R2 because we've configured FL to have standard-conforming behavior on our zone so that might be another source of difference. Not sure.

[vlovich]

Actually, even our HEAD response has encodeBody: 'manual',

[vlovich]

Also, the content-encoding we're setting isn't one of the supported ones so it seems weird to delete content length in that case.