Client (web browser) hangs if body not consumed

[fishcakeday]

When trying to abort POST request when using Hono with node-server, it is impossible to abort without consuming the whole body (which is wasteful, especially for large uploads).

Tried with node versions:
v22.17.0
v24.3.0

Hono 4.8.2
Hono 4.8.3

Below is the simplest example:

import { serve } from "@hono/node-server";
import { HTTPException } from "hono/http-exception";
import { Hono } from "hono";

const app = new Hono();

// Works
app.post(
  "/upload1",
  async (ctx) => {
    if (!ctx.req.raw.body) {
      throw new HTTPException(400, { message: "No file data received" });
    }
    // Create "/dev/null" writeable stream, without this the client will hang
    const nullStream = createWriteStream("/dev/null");
    ctx.req.raw.body.pipeTo(Writable.toWeb(nullStream))

    return ctx.json({ ok: "ok" });
  },
);

// Works
app.post(
  "/upload2",
  async (ctx) => {
    return ctx.json({ ok: "ok" });
  },
);

// Hangs
app.post(
  "/upload3",
  async (ctx) => {
    if (!ctx.req.raw.body) {
      throw new HTTPException(400, { message: "No file data received" });
    }

    return ctx.json({ ok: "ok" });
  },
);

// Hangs
app.post(
  "/upload4",
  async (ctx) => {
    if (!ctx.req.raw.body) {
      throw new HTTPException(400, { message: "No file data received" });
    }
    ctx.req.raw.body.cancel();
    return ctx.json({ ok: "ok" });
  },
);

serve(
  {
    fetch: app.fetch,
    port: 3000,
  },
  (info) => {
    console.log(`Server is running on http://localhost:${info.port}`);
  },
);

I suspect it is because of the how it is done in the following part, but I am speculating here.

node-server/src/request.ts

Line 88 in 0e35e65

init.body = Readable.toWeb(incoming) as ReadableStream<Uint8Array>

[fishcakeday]

It would appear the node-server does not destroy the incoming connection unless "close" was emitted. (ctx.env.incoming as IncomingMessage)?.emit("close"); (if we define binding with incoming / outgoing thanks to #129 ).

I suspect that something is either not closing the incoming as it should, or

node-server/src/listener.ts

Line 189 in 0e35e65

outgoing.on('close', () => {

is wrong.

[yusukebe]

@fishcakeday Thank you for raising the issue.

Hi @usualoma, sorry for pinging again. Can you take a look at this?

[usualoma]

Okay, I'll take a look.

[yusukebe]

Thanks!

[usualoma]

Update at 7/10 : A slight change

Standard configuration of the app to be reproduced

Looking at the ticket comments, this seems to be a special case, but this issue can be reproduced in a standard configuration by using bodyLimit.

import { serve } from '@hono/node-server'
import { Hono } from 'hono'
import { bodyLimit } from 'hono/body-limit'

const app = new Hono()

app.post(
  '/upload',
  bodyLimit({ maxSize: 50 * 1024 }),
  async (ctx) => {
        const contentLength = (await ctx.req.raw.text()).length
        return ctx.json({ ok: `ok: ${contentLength}` })
  },
)

serve(
  {
    fetch: app.fetch,
    port: 3000,
  },
  (info) => {
    console.log(`Server is running on http://localhost:${info.port}`)
  },
)

If you run the following script, the server will not disconnect, so you will have to wait until the timeout expires.

const http = require('http')

const generateLargeData = (sizeInMB) => {
  const sizeInBytes = sizeInMB * 1024 * 1024
  const chunk = Buffer.alloc(1024, 'A')
  const chunks = []

  for (let i = 0; i < sizeInBytes / 1024; i++) {
    chunks.push(chunk)
  }

  return Buffer.concat(chunks)
}

const attackUpload = () => {
  return new Promise((resolve, reject) => {
    const data = generateLargeData(100) // 100MB
    const contentLength = data.length

    console.log(`Generating ${contentLength} bytes (${contentLength / (1024 * 1024)} MB) of data...`)

    const options = {
      hostname: 'localhost',
      port: 3000,
      path: '/upload',
      method: 'POST',
      headers: {
        'Content-Type': 'application/octet-stream',
        'Content-Length': contentLength,
        'Connection': 'keep-alive'
      }
    }

    const req = http.request(options, (res) => {
      console.log(`Response status: ${res.statusCode}`)
      console.log('Response headers:', res.headers)

      let responseData = ''
      res.on('data', (chunk) => {
        responseData += chunk
      })

      res.on('end', () => {
        console.log(`Response body: ${responseData}`)

        req.socket.on('close', () => {
          console.log('Server closed the connection')
          resolve()
        })

        req.socket.on('error', (err) => {
          console.log('Socket error:', err.message)
          resolve()
        })

        setTimeout(() => {
          console.log('Timeout reached, closing connection manually')
          req.socket.end()
          reject(new Error('Timeout'))
        }, 10000)
      })
    })

    req.on('error', (err) => {
      console.error('Request error:', err.message)
      reject(err)
    })

    req.on('socket', (socket) => {
      console.log('Socket created, starting data transmission...')

      req.write(data)
      req.end()

      console.log('Data transmission completed')
    })
  })
}

console.log('Starting upload attack test...')
attackUpload()
  .then(() => {
    console.log('Attack test completed')

    process.exit(0)
  })
  .catch((err) => {
    console.error('Attack test failed:', err)

    process.exit(1)
  }) 

[usualoma]

I have updated the comment above.

The following conclusions can be drawn from these results.

• This is more of a server-side issue than a client-side issue.
• If the app does not read the entire request body, node-server will not automatically close the incoming socket.
  • However, this problem will not occur if the app does not call Readable.toWeb(incoming) (i.e., if it does not even reference the body).
• Even if the application thinks it has returned a response, the connection may remain open, potentially causing a resource leak.

However, the situation where “the request body is not fully read” is extremely rare, so this issue is unlikely to occur in typical applications.

[fishcakeday]

How is this rare? Did you never had a post request rejected by the server? Doesn't bodySize middleware do it too? Did you never had a server generate http-500 during a post/put request? "is extremely rare" is a wrong assertion, especially when you deal with the internet. Any leak is a potential threat to availability, or security. Unread post/put requests are common given large enough traffic.