Node's HTTP client fails on Bun's chunked/malformed HTTP response

[JeffreyATW]

What version of Bun is running?

1.0.7

What platform is your computer?

Darwin 23.0.0 x86_64 i386

What steps can reproduce the bug?

Install the repo at https://github.com/JeffreyATW/bun-write-test

Or just write this code and observe the differences between Bun and Node in Wireshark:

import http from "http";

http.createServer((req, res) => {
  res.setHeader('Content-Type', 'text/html');
  res.write("hello");
  res.end("end");
}).listen(3000, () => {
  console.log('http://localhost:3000');
});

See bunserver.pcapng and nodeserver.pcapng for sample packet captures.

What is the expected behavior?

Node returns an HTTP chunked response with 5 octets, followed by 3 octets, followed by an 0 octet end of chunked encoding.

What do you see instead?

Bun returns something else. It's hard to parse. It looks like it response with a content-length of 8 (correctly), but then the same packet contains multiple additional HTTP responses with a transfer-encoding of chunked.

Wireshark complains "Leading CRLF previous message in the stream may have extra CRLF".

This doesn't cause problems in regular browsers, but when Cypress attempts to proxy the Bun server to run e2e tests (or a vanilla Node http.get call is made to Bun's server), it has trouble parsing the response and returns an HPE_INVALID_CONSTANT error, and the page doesn't load, causing my tests to fail.

Additional information

I filed a similar issue with Cypress, but it turns out that this is an underlying issue with Node's HTTP response parser.

Regardless, the shape of the HTTP response packet is significantly different than what I see when running this rather simple server code in Node.

[patriksimms]

@JeffreyATW did you found an workaround for this? This issue is puzzeling us quite a bit.

What is interesting: The issue only seems to appear when the bun server & consuming node service are running locally (or locally in docker). When we are using our deployed bun service and sending the request from the local node service, it works.

Turns out that when an reverse proxy is in place, it works also locally. So for example nginx does something with the response it receives from bun which works then later for the consuming noce service.

[Jarred-Sumner]

@patriksimms is nginx configured to use HTTP 1.1? by default, nginx sets the HTTP version to 1.0 and HTTP version 1.0 is not recommended

[patriksimms]

@Jarred-Sumner We tried proxy_http_version 1.0; and proxy_http_version 1.1;, both behave the same and are working

[JeffreyATW]

I did not find a workaround for this.

[Jarred-Sumner]

Are you still running into this issue? We've fixed many bugs with the HTTP client since this issue

[JeffreyATW]

The commands in my test repo I linked above all seem to succeed now, so I think it's been fixed!