Drop Set-Cookie from the recovered 500 (closes #193) #337

Merged
clawbot merged 1 commits from issue-193-clear-set-cookie-on-recovered-500 into next 2026-09-29 10:30:27 +02:00
Collaborator

Closes #193, option 3 as decided in #193 (comment).

When a handler sets a cookie and then panics before sending anything, the recover middleware (internal/middleware/recoverer.go) now deletes Set-Cookie before writing its 500, so a request that failed never hands the client a credential. Every other header, Location included, is left as http.Error leaves it, which is what chi's Recoverer does. A response that was already sent before the panic is untouched: nothing can be taken back once it is on the wire, and there is still no second WriteHeader.

The doc comment on Recoverer records this in one sentence, so the difference from http.Error is not taken for a bug.

Tests:

  • a handler that sets Set-Cookie and Location and panics uncommitted gets a 500 with no cookie and its Location kept; removing the deletion fails it;
  • the existing committed-response test now also sets a cookie and asserts it still reaches the client.

Worth knowing: the header map is shared along the whole middleware chain, so a cookie set by a middleware further out than the recoverer would be dropped too. None of the current outer middlewares (request id, security headers, access log, metrics, CORS, timeout) sets one.

Model: opus-5-5

Closes https://git.eeqj.de/sneak/webhooker/issues/193, option 3 as decided in https://git.eeqj.de/sneak/webhooker/issues/193#issuecomment-106293. When a handler sets a cookie and then panics before sending anything, the recover middleware (`internal/middleware/recoverer.go`) now deletes `Set-Cookie` before writing its 500, so a request that failed never hands the client a credential. Every other header, `Location` included, is left as `http.Error` leaves it, which is what chi's `Recoverer` does. A response that was already sent before the panic is untouched: nothing can be taken back once it is on the wire, and there is still no second `WriteHeader`. The doc comment on `Recoverer` records this in one sentence, so the difference from `http.Error` is not taken for a bug. Tests: - a handler that sets `Set-Cookie` and `Location` and panics uncommitted gets a 500 with no cookie and its `Location` kept; removing the deletion fails it; - the existing committed-response test now also sets a cookie and asserts it still reaches the client. Worth knowing: the header map is shared along the whole middleware chain, so a cookie set by a middleware further out than the recoverer would be dropped too. None of the current outer middlewares (request id, security headers, access log, metrics, CORS, timeout) sets one. Model: opus-5-5
clawbot added the needs-review label 2026-09-29 09:37:37 +02:00
clawbot self-assigned this 2026-09-29 09:37:37 +02:00
clawbot added 1 commit 2026-09-29 09:37:38 +02:00
Drop Set-Cookie from the recovered 500 (closes #193)
check / check (push) Successful in 4m20s
7ca033021c
When a handler sets a cookie and then panics before sending
anything, the recover middleware now deletes Set-Cookie before
writing its 500, so a request that failed never hands the client
a credential. Every other header, Location included, is left as
http.Error leaves it, matching chi's Recoverer. A response that
was already sent is untouched.

Tests cover the uncommitted case (no cookie, Location kept) and
assert the cookie still reaches the client when the response was
committed before the panic.

Model: opus-5-5
Author
Collaborator

Review passed.

Model: opus-5-5

Review passed. Model: opus-5-5
clawbot merged commit f0adeafde3 into next 2026-09-29 10:30:27 +02:00
clawbot deleted branch issue-193-clear-set-cookie-on-recovered-500 2026-09-29 10:30:27 +02:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/webhooker#337