🐛 BUG: wrangler dev doesn't stream compressed response while deployed workers do

[hi-ogawa]

Which Cloudflare product(s) does this pertain to?

Wrangler

What version(s) of the tool(s) are you using?

3.72.2 (the issue happens since 3.49.0)

What version of Node are you using?

20.17.0

What operating system and version are you using?

Linux 6.10 Arch Linux

Describe the Bug

Observed behavior

It looks like wrangler dev is not streaming compressed response, for example, for browser's text/html request. The example code is included below in the reproduction and following screenshots show the difference between wrangler dev and deployed workers:

Screenshots

wrangler dev http://localhost:8787

Screencast.from.2024-08-24.19-16-18.webm

deployed version https://repro-wrangler-stream-response.hiro18181.workers.dev

Screencast.from.2024-08-24.19-18-00.webm

Expected behavior

wrangler dev should work similar to deployed version.

Steps to reproduce

reproduction is provided below

Please provide a link to a minimal reproduction

https://github.com/hi-ogawa/reproductions/tree/main/wrangler-stream-response

Please provide any relevant error logs

No error logs

Additional context

I initially discovered this issue in hi-ogawa/vite-plugins#523 when upgrading wrangler >= 3.49.0. I have e2e tests for React streaming SSR (content-type text/html) and also RSC requests (content-type text/x-component). While deployed version works in both cases (for example https://rsc-experiment.hiro18181.workers.dev/test/loading/1), but equivalent tests for wrangler dev are failing since wrangler 3.49.0.

I'm not entirely sure whether streaming response is reliable when there is a compression and maybe some variance is expected. I would appreciate if there's any clarification on this if this is an expected behavior.

For example, the deployed version in the reproduction wasn't actually streaming properly until I put "dummy comment" to the streaming payload https://github.com/hi-ogawa/reproductions/blob/b718cf55c782e200d61b319132be1469d26800f0/wrangler-stream-response/index.js#L19-L20 Perhaps, compressed streaming depends on the size of the payload in practice?

Another thing, probably not relevant to wrangler but just in case, vite preview has non-streaming compression, so I often strip off accept-encoding from middleware to allows testing streaming SSR https://github.com/hi-ogawa/vite-plugins/blob/b446fcc6833a55987ef1ac0a9fc6479ea8246e52/packages/react-server/examples/basic/vite.config.ts#L57-L67 If there's any workaround like this to test streaming response of wrangler dev, then that would be great too (though probably it's not ideal to turn off compression since that would be bigger inconsistency with deployed workers).

[MaxBittker]

still affected by this, are there any workarounds besides downgrading?

[sleexyz]

bumping this, this breaks any kind of streaming response i.e. LLM response output.

[hi-ogawa]

As a workaround, it looks like you can force no compression by adding content-encoding: identify, which should enable streaming. I just learned this from Hono honojs/hono#3449

In my reproduction, it would look like this:

	return new Response(stream, {
		headers: {
			"content-type": "text/html",
			"content-encoding": "identity",
		},
	});