Fursy v0.6.3 - Global Body Limit Now Covers All Handlers

Fursy v0.6.3 shipped on 2026 October 8. The headline change is a security fix: SetMaxBodySize is now enforced for all handlers in ServeHTTP, not just generic ones. Plain handlers registered with router.Handle() previously accepted unlimited bodies.

The full release notes and downloads are on the GitHub release page.

The body limit gap, closed ¶

Before this release, the body limit configured through SetMaxBodySize only applied to generic handlers. Endpoints registered directly via router.Handle() skipped the check entirely. On an internet facing service that is an unbounded read into memory, which turns into a trivial resource exhaustion vector.

The fix moves enforcement into ServeHTTP so it covers every registration path.

The tradeoff is explicit in the notes: existing Handle() endpoints that accept bodies larger than 4MB will now receive 413 responses. The 4MB value is the configured default, so anything above it gets rejected at the boundary instead of being read.

If you have a legitimate large upload path on a plain handler, call SetMaxBodySize(0) to disable the limit. Do that consciously, per service, not as a blanket default.

For operators running fursy as the ingestion edge for ETL pipelines, this is the kind of change to catch before a production deploy: a batch exporter posting large payloads through a plain handler will start failing with 413s after upgrade.

A new hook, SetErrorLogger(func(error, *http.Request)), fires for unclassified errors just before the 500 goes out. Two details matter:

  • It fires even on partially written responses, so streaming failures that would otherwise vanish into a broken response are now observable.
  • It deliberately does not fire on classified errors such as Problem or ValidationErrors. Those already have structured handling; the hook is for the uncategorized remainder.

This is a cheap way to get telemetry on the errors that previously produced an unexplained 500 and nothing in the logs.

The release adds two fuzz targets, FuzzRadixLookup and FuzzRoutePattern, run for roughly 3.3 million executions with no panics found. For a router, that is the right place to spend fuzzing effort: pattern parsing and radix lookup are the code paths that take attacker controlled URL input.

A documentation fix closes the release: CORS must be registered before auth middleware. If you wired them the other way, preflight requests get rejected by the auth layer before CORS handling runs.