set res() setter loses Set-Cookie headers when middleware sets cookies before next() and handler returns a raw Response

[techzealot]

What version of Hono are you using?

4.12.18

What runtime/platform is your app running on? (with version if possible)

Node.js v24.1.0

What steps can reproduce the bug?

When a middleware sets a Set-Cookie header via c.header() before await next(), and the downstream handler returns a raw Response object with its own Set-Cookie headers, one side's cookies are always lost — they are never merged correctly.

Minimal reproduction (no third-party dependencies):

import { Hono } from 'hono'

const app = new Hono()

// Middleware: access c.res (e.g. CORS does this), then set a cookie
app.use(async (c, next) => {
  c.res.headers.set('X-Something', 'true') // triggers #res creation
  c.header('Set-Cookie', 'mw_cookie=hello; Path=/', { append: true })
  await next()
})

// Handler: returns a raw Response with its own Set-Cookie
app.get('/test', (c) => {
  const res = new Response('ok')
  res.headers.append('set-cookie', 'handler_cookie=world; Path=/; HttpOnly')
  return res
})

const res = await app.request('/test')
console.log(res.headers.getSetCookie())
// Actual:   ['mw_cookie=hello; Path=/']
// Expected: ['mw_cookie=hello; Path=/', 'handler_cookie=world; Path=/; HttpOnly']

What is the expected behavior?

Both Set-Cookie headers should be present in the final response:

• mw_cookie=hello (set by middleware via c.header())
• handler_cookie=world (set by the handler's raw Response)

What do you see instead?

Only one side's cookies survive, depending on whether c.res was accessed before c.header():

Scenario	#res created before c.header()?	Lost cookies
A: No middleware touches c.res early	No	c.header() cookies lost (merge skipped entirely)
B: Some middleware accesses c.res early (e.g. CORS)	Yes	Handler's cookies overwritten

Additional information

Root cause

The bug is in the set res() setter in src/context.ts:

set res(_res) {
  if (this.#res && _res) {          // ← Scenario A: #res is falsy → entire merge is skipped
    _res = createResponseInstance(_res.body, _res)
    for (const [k, v] of this.#res.headers.entries()) {
      if (k === 'set-cookie') {
        const cookies = this.#res.headers.getSetCookie()
        _res.headers.delete('set-cookie')   // ← Scenario B: deletes handler's cookies
        for (const cookie of cookies) {
          _res.headers.append('set-cookie', cookie)  // ← only re-appends context's cookies
        }
      }
      // ...
    }
  }
  this.#res = _res
}

Scenario A — this.#res is undefined (no middleware accessed c.res before c.header()):

• c.header() writes to #preparedHeaders, but the if (this.#res && _res) guard is false
• #preparedHeaders are never merged into the handler's Response → middleware cookies lost

Scenario B — this.#res exists (e.g. CORS middleware called c.res.headers.set() earlier):

• _res.headers.delete('set-cookie') wipes ALL cookies from the handler's Response
• Only the context's cookies are re-appended → handler cookies lost

Suggested fix

The merge logic should preserve cookies from both sides:

// this only fix Scenario B
if (k === 'set-cookie') {
  // Collect cookies from both sources before mutating
  const handlerCookies = _res.headers.getSetCookie()
  const contextCookies = this.#res.headers.getSetCookie()
  _res.headers.delete('set-cookie')
  for (const cookie of handlerCookies) {
    _res.headers.append('set-cookie', cookie)
  }
  for (const cookie of contextCookies) {
    _res.headers.append('set-cookie', cookie)
  }
}

Additionally, Scenario A needs #preparedHeaders to be merged even when #res hasn't been created yet.

Real-world impact

This bug surfaces in common middleware combinations. For example, in our project:

CORS middleware (accesses c.res.headers)
  → languageDetector({ caches: true })   // calls setCookie() → c.header("Set-Cookie", ...)
    → better-auth handler                // returns raw Response with session Set-Cookie headers

With caches: true, the languageDetector sets a language cookie via c.header() before next(). When better-auth's handler returns a raw Response with session cookies, the set-cookie merge in set res() causes cookies from one side to be dropped.

We currently work around this by setting caches: false, but this disables a legitimate feature. The issue is not specific to languageDetector or better-auth — any middleware that calls c.header('Set-Cookie', ...) before next() combined with any handler that returns a raw Response with Set-Cookie headers will trigger this bug.

[usualoma]

Hi @techzealot,
Thanks for creating the issue. I’d like to fix this.

I’m wondering if we should define a unified merge rule for this.#res and this.#preparedHeaders, even though that would be a partial breaking change.

My proposal would be:

• Put context/prepared headers first.
• Prefer the raw Response's content-type.
• Let normal headers from the raw Response overwrite context/prepared headers.
• Append raw Response Set-Cookie values after context/prepared Set-Cookie values.
• Do not dedupe Set-Cookie; Hono should not interpret cookie identity.

This would make the behavior consistent between this.#res and this.#preparedHeaders, and the rule seems easier to explain.

For example:

set res(_res: Response | undefined) {
  if ((this.#res ?? this.#preparedHeaders) && _res) {
    const headers = new Headers(this.#res?.headers ?? this.#preparedHeaders)
    headers.delete('content-type')

    let setCookieHandled = false
    for (const [k, v] of _res.headers.entries()) {
      if (k === 'set-cookie') {
        if (setCookieHandled) {
          continue
        }
        setCookieHandled = true
        for (const cookie of _res.headers.getSetCookie()) {
          headers.append('set-cookie', cookie)
        }
      } else {
        headers.set(k, v)
      }
    }

    _res = createResponseInstance(_res.body, {
      headers,
      status: _res.status,
      statusText: _res.statusText,
    })
  }
  this.#res = _res
  this.finalized = true
}

Hi @yusukebe,
What do you think?

[yusukebe]

@techzealot Thank you for the issue.

Hi @usualoma!

My concern is only for performance and breaking changes.

For performance, new Headers() is a little costly. But if it's on the fast path, like using c.text() without middleware, it does not use set res. So, I think it's okay with your code.

For breaking changes, some tests fail, but fixing this issue is prioritized rather than failing correct tests.

One thing I found is that the following behavior is unexpected, right?

const app = new Hono()

app.use(async (c, next) => await next())

app.get('/', (c) => {
  c.header('Set-Cookie', 'a=1')
  return c.text('Hi')
})

const res = await app.request('/')
console.log(res.headers.getSetCookie()) // [ "a=1", "a=1" ]

[usualoma]

I see. I hadn't noticed that pattern. In that case, we can't ignore the performance either.

[usualoma]

example 1

This behavior has been around for a long time, and while I don’t think it’s a major use case, even in the simple example below it seems inconsistent, so I think it would be better to improve it after all.

import { Hono } from './src'

const app = new Hono()

app.use(async (c, next) => {
  c.header('X-Powered-By-Before', 'Hono')
  await next()
  c.header('X-Powered-By-After', 'Hono')
})

app.get('/', (c) => {
  return c.req.query('raw-response') ? new Response('Hi') : c.text('Hi')
})

export default app

% curl -i 'http://localhost:3000'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
X-Powered-By-Before: Hono
X-Powered-By-After: Hono
Date: Sun, 07 Jun 2026 06:32:49 GMT
Content-Length: 2

Hi

% curl -i 'http://localhost:3000?raw-response=1'
HTTP/1.1 200 OK
X-Powered-By-After: Hono
content-type: application/octet-stream
Date: Sun, 07 Jun 2026 06:32:50 GMT
Content-Length: 2

Hi

example 2

Also, while this isn’t a primary use case either, calling c.text() multiple times may result in unintended headers being included.

import { Hono } from './src'

const app = new Hono()

app.get('/', (c) => {
  c.header('X-Powered-By', 'Hono')
  const res1 = c.text('Hi', {
    headers: {
      'Res1': 'Value1',
    },
  })
  const res2 = c.text('Hi', {
    headers: {
      'Res2': 'Value2',
    },
  })
  return c.req.query('res') != null ? res1 : res2
})

export default app

% curl -i 'http://localhost:3000'
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
X-Powered-By: Hono
res1: Value1
res2: Value2
Date: Sun, 07 Jun 2026 06:50:51 GMT
Content-Length: 2

Hi

It’s a tough call whether we should go ahead and make some adjustments to this area.

[usualoma]

Although there will be some overhead in the following areas, I think #5008 is the best option for ensuring consistent behavior while minimizing changes to the current implementation.

https://github.com/honojs/hono/pull/5008/changes#diff-0cd594dddd6a9f2e3e26afebbb92716434437d7001c2416252aa7531e7f2b8d4R665