Behaviour mismatch: Fetch with content-length: 0 fails with undici error

[orls]

Attempting to fetch with content-length: 0 results in an error from undici. This is tolerated in real Workers env:

Steps to reproduce:

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  return fetch('https://httpbin.org/delete', {
    method: 'DELETE',
    headers: {
      'Accept': 'application/json',
      'Content-length': '0'
    }
  });
}

expected behaviour:

Request succeeds (worker returns the httpbin 200 response).

Actual behaviour

[mf:err] GET /: TypeError: fetch failed
    at Object.processResponse (/somedir/node_modules/undici/lib/fetch/index.js:176:23)
    at fetchFinale (/somedir/node_modules/undici/lib/fetch/index.js:737:17)
    at Fetch.mainFetch (/somedir/node_modules/undici/lib/fetch/index.js:712:5)
[mf:err] Cause: RequestContentLengthMismatchError: Request body length does not match content-length header
    at write (/somedir/node_modules/undici/lib/client.js:1433:37)
    at _resume (/somedir/node_modules/undici/lib/client.js:1385:29)
    at resume (/somedir/node_modules/undici/lib/client.js:1244:3)
    at connect (/somedir/node_modules/undici/lib/client.js:1229:3)
GET / 500 Internal Server Error (329.42ms)

---

This originates from undici's strictness; they deliberately treat the req as invalid, it's not a bug from their POV. See undici issue 649 for example. They offer a non-strict mode to turn this and other behaviours into warnings, but I don't think miniflare supports enabling this mode?

This does not match behaviour of CF deployed workers. Moreover, there is code in the wild that explicitly and deliberately adds content-length: 0 to certain requests. For example, popular NPM lib node-http-proxy; I believe Envoy proxy does similar.

---

(this shares some DNA with recent miniflare issues like #183 and #182: undici's design goals, while reasonable in some contexts, don't always seem to align with CF Workers' server-side-oriented fetch impl)

[mrbbot]

Hey! 👋 Thanks for raising this. Should be possible to remove the Content-Length header if it's 0 in fetch:

miniflare/packages/core/src/standards/http.ts

Lines 762 to 769 in b887877

	req.headers[fetchSymbols.kGuard] = "none";
	// Delete the "Host" header, the correct value will be added by undici
	req.headers.delete("host");
	// Delete the "CF-Connecting-IP" header, if we didn't do this, we'd get a 403
	// response when attempting to make requests to sites behind Cloudflare
	req.headers.delete("cf-connecting-ip");
	// Add "MF-Loop" header for loop detection
	req.headers.set(_kLoopHeader, String(ctx?.requestDepth ?? 1));

[dpeek]

Any chance this could be released as a patch version? I ran into the Stripe SDK issue so I'm using a yarn link version... looks like 2.4.0 is a ways off 😅

[CraigglesO]

I second @dpeek , I've been running a personal duplicate of Stripe that removes the header if 0 for now, but would be nice to be able to keep up with Stripe updates.

[mrbbot]

Hey! 👋 I've just released version 2.4.0 including the fix for this. You can find the full changelog here.