Fiber's Buffer Reuse: Why Request Values Disappear and How to Fix It

The Problem: Values That Vanish After the Handler Returns

You're building a Fiber service. A handler reads c.Body(), stores it in a struct, and passes that struct to a background goroutine for async processing. Under load, the stored JSON starts showing fragments from other requests—or turns into garbage entirely. The handler logic looks correct. The bug isn't in your code; it's in a deliberate performance decision Fiber inherits from fasthttp.

Takeaway: By default, slices and strings returned from fiber.Ctx methods (Params, Query, Body, FormValue, etc.) are backed by buffers that fasthttp recycles the moment your handler returns. If you retain those values beyond the handler’s lifetime, you’re holding references to memory that will be overwritten by the next request.

Why Fiber Does This: Zero-Allocation Hot Paths

fasthttp (the engine under Fiber) avoids per-request allocations by reusing a single set of byte buffers for headers, body, and parsed values across requests. When c.Body() returns a []byte, it’s a slice pointing into that shared buffer. The moment the handler finishes, the buffer is cleared and reused for the next incoming request. This is why Fiber benchmarks well on throughput and latency—it eliminates the allocation pressure that net/http frameworks incur.

The trade-off is explicit: values are valid only until the handler returns. This is documented, but it catches developers coming from net/http where r.Body and r.FormValue return independent copies.

The Immutable Switch: Safety at a Cost

Fiber exposes fiber.Config{Immutable: true}. When enabled, every Ctx accessor that would return a buffer-backed value instead returns a fresh copy. c.Body() allocates a new []byte and copies the data. c.Params("id") allocates a new string. Your retained values are now safe to use in goroutines, channels, or long-lived caches.

The cost is measurable: every request on every handler pays the allocation and copy overhead, even for values that never escape. On a hot path serving 50k req/s, that’s tens of megabytes per second of extra GC pressure. For many services the cost is acceptable; for latency-sensitive paths it can be the difference between p99 < 5 ms and p99 > 20 ms.

Pragmatic Pattern: Copy Only What Escapes

Instead of flipping Immutable globally, keep it off (the default) and copy only the values that actually leave the handler. This gives you zero-allocation fast paths for the majority of requests while making the escape explicit and auditable.

func ingest(c *fiber.Ctx) error {
    body := make([]byte, len(c.Body()))
    copy(body, c.Body())
    go processAsync(body) // safe: body is independent
    return c.SendStatus(fiber.StatusAccepted)
}

If multiple values escape, copy them individually or use a small helper:

func copyCtxValues(c *fiber.Ctx, keys ...string) map[string]string {
    out := make(map[string]string, len(keys))
    for _, k := range keys {
        out[k] = c.Params(k) // string copy on assignment
    }
    return out
}

Note: assigning a string returned from c.Params or c.Query to a new variable does create a copy in Go, because strings are immutable. The danger is with []byte returns (Body, Context methods) where the slice header points to the shared buffer.

Worked Example: Reproducing the Corruption

You can verify the behavior in your own codebase with a minimal test. Run this against your Fiber version (tested on v2.x; behavior is version-sensitive—see limitations).

package main

import (
    "fmt"
    "sync/atomic"
    "time"
    "github.com/gofiber/fiber/v2"
)

var stored atomic.Pointer[[]byte]

func main() {
    app := fiber.New() // Immutable defaults to false
    app.Post("/echo", func(c *fiber.Ctx) error {
        // BUG: retaining buffer-backed slice
        stored.Store(&[]byte(c.Body()))
        return c.SendString("ok")
    })

    go func() {
        for {
            time.Sleep(100 * time.Millisecond)
            if p := stored.Load(); p != nil {
                fmt.Printf("stored len=%d first=%v\n", len(*p), (*p)[:min(8, len(*p))])
            }
        }
    }()

    app.Listen(":3000")
}

func min(a, b int) int { if a < b { return a }; return b }

Run it: go run main.go (requires Go 1.19+ for atomic.Pointer). In another terminal, send two requests:

curl -X POST -d 'first-request-body' http://localhost:3000/echo
curl -X POST -d 'second-request-body-different' http://localhost:3000/echo

Observe: The background printer will show the stored value change from first-request-body to second-request-body-different even though you only stored once. The buffer was reused.

Fix: Change the handler to copy:

body := make([]byte, len(c.Body()))
copy(body, c.Body())
stored.Store(&body)

Rerun the same two curls. The stored value now remains first-request-body.

Verify with Immutable: Change fiber.New() to fiber.New(fiber.Config{Immutable: true}) and revert the handler to the buggy version. The stored value will stay stable—but every request now allocates.

Limitations and Version Sensitivity

• Fiber major version matters. The research covers v2.x semantics. v3 or later may change which methods return buffer-backed values or how Immutable interacts with specific accessors. Always check the release notes for your version.
• Not all Ctx methods are affected. c.IP(), c.Method(), c.Path() typically return new strings. c.Body(), c.Context() (the underlying fasthttp.RequestCtx), and form/file accessors are the primary culprits.
• net/http middleware adapters add indirection. Wrapping a net/http handler via fiber.New(fiber.Config{...}) or adapter packages can mask the buffer lifetime, because the adapter may copy data before calling your handler—or it may not. Test the specific adapter you use.
• Benchmarks vary by workload. The allocation cost of Immutable: true is proportional to request size and number of accessor calls. A JSON API with 1 KB bodies behaves differently than a file‑upload endpoint with 10 MB bodies. Profile with pprof (go tool pprof -alloc_space) under realistic load before deciding.

How to Check Your Codebase Today

1. Grep for retained Ctx values. Search for patterns like c\.Body(), c\.Params(), c\.Query() assigned to package-level variables, sent to channels, or passed to goroutines.
2. Add a test that simulates the race. Use the example above as a template: store a value, fire a second request, assert the stored value is unchanged.
3. Decide per-handler. For each escape site, either copy manually (preferred for hot paths) or enable Immutable on a sub‑router mounted only for those routes: app.Use("/webhooks", fiber.New(fiber.Config{Immutable: true})).
4. Measure. Run hey -n 100000 -c 100 http://localhost:3000/your-endpoint with and without your changes. Compare go tool pprof -alloc_space profiles and latency percentiles.

Fiber’s speed comes from a clear contract: you own the lifetime of values you keep. Respect the buffer reuse on your hot paths, copy explicitly when values escape, and reserve Immutable for the edges of your system where safety outweighs allocation cost.