[Audit] fiber: /compression bypasses Fiber built-in compression middleware

[jerrythetruckdriver]

Rule violated

@Kaliumhexacyanoferrat

Use framework-level APIs — "If a framework provides a documented, high-level way to accomplish a task, the benchmark implementation must use it."

Details

Fiber provides a well-documented compression middleware at github.com/gofiber/fiber/v2/middleware/compress. The implementation ignores it entirely and hand-rolls compression using Go stdlib compress/flate and compress/gzip:

File: frameworks/fiber/main.go, /compression handler (~line 155)

ae := c.Get("Accept-Encoding")
if strings.Contains(ae, "deflate") {
    c.Set("Content-Encoding", "deflate")
    w, err := flate.NewWriter(c.Response().BodyWriter(), flate.BestSpeed)
    // ...
} else if strings.Contains(ae, "gzip") {
    c.Set("Content-Encoding", "gzip")
    w, err := gzip.NewWriterLevel(c.Response().BodyWriter(), gzip.BestSpeed)
    // ...
}

The framework middleware handles Accept-Encoding negotiation, content-encoding headers, and compression level configuration. Bypassing it means the benchmark no longer measures Fiber's compression — it measures Go's stdlib compressors with Fiber's routing on top.

Suggested fix

Use Fiber's built-in middleware:

import "github.com/gofiber/fiber/v2/middleware/compress"

app.Use("/compression", compress.New(compress.Config{
    Level: compress.LevelBestSpeed,
}))

app.Get("/compression", func(c *fiber.Ctx) error {
    c.Set("Server", "fiber")
    c.Set("Content-Type", "application/json")
    return c.Send(jsonLargeResponse)
})

This keeps the measurement honest — users want to know how Fiber's compression performs, not how stdlib performs behind Fiber's router.

[BennyFranciscus]

Good catch. Yeah, the compression handler is manually wiring up compress/flate and compress/gzip writers instead of going through github.com/gofiber/fiber/v2/middleware/compress. That's exactly the kind of thing the "use framework-level APIs" rule is meant to catch — if Fiber ships compression middleware, the benchmark should use it so we're measuring Fiber's compression pipeline, not raw Go stdlib.

The suggested fix with compress.New(compress.Config{Level: compress.LevelBestSpeed}) scoped to /compression looks right. Fiber's middleware handles Accept-Encoding negotiation and header management internally, so the handler just needs to send the uncompressed response body and let the middleware take care of the rest.

Worth noting this is the same pattern as my PRs #136 (ktor) and #148 (actix) — switching from hand-rolled or default-level compression to the framework's own mechanism at level 1. Would be happy to open a PR for this if @MDA2AV wants.

[MDA2AV]

frameworks only need to apply compression on /compression endpoint, keep that in mind - if it is not possible to have that while using the middleware we can't use it. it should be possible though, the middleware should be configured to apply on certain endpoints? Otherwise it will also trigger on the /json test?

if framework is working properly it should only use compression if the request defines it in its headers? @BennyFranciscus

[BennyFranciscus]

Good point — yeah, Fiber's compress middleware supports a Next callback that lets you skip it for specific routes. You'd invert the logic to only apply it on /compression:

app.Use(compress.New(compress.Config{
    Level: compress.LevelBestSpeed,
    Next: func(c fiber.Ctx) bool {
        return c.Path() != "/compression"
    },
}))

This way the middleware only fires for /compression and is a no-op for everything else. The middleware itself already handles Accept-Encoding negotiation — it checks for gzip/deflate/brotli/zstd in the header and only compresses if the client supports it. So if a request to /compression doesn't send Accept-Encoding: gzip, the body goes through uncompressed. No double-triggering on /json or other endpoints.

Alternatively you could scope it to a route group:

compressionGroup := app.Group("/compression")
compressionGroup.Use(compress.New(compress.Config{Level: compress.LevelBestSpeed}))
compressionGroup.Get("/", compressionHandler)

Either approach works. The Next callback is simpler for a single endpoint.

[MDA2AV]

we should go with the framework knowing when to compress given that the client sent the Accept-Encoding: gzip - that's how it should be

[BennyFranciscus]

Exactly — register the middleware globally, let Fiber handle the Accept-Encoding negotiation itself. Clients that send Accept-Encoding: gzip get compressed responses, others don't. No per-route filtering needed.

I'll open a PR that swaps out the manual flate/gzip writers for compress.New(compress.Config{Level: compress.LevelBestSpeed}) applied globally. The compression test already sends the right header so it'll just work, and the other endpoints won't compress since wrk doesn't send Accept-Encoding by default.

Quick sanity check — should I also remove the manual Content-Encoding header setting in the compression handler, or just strip the whole manual implementation and let the middleware own the full pipeline?

[MDA2AV]

Exactly — register the middleware globally, let Fiber handle the Accept-Encoding negotiation itself. Clients that send Accept-Encoding: gzip get compressed responses, others don't. No per-route filtering needed.

I'll open a PR that swaps out the manual flate/gzip writers for compress.New(compress.Config{Level: compress.LevelBestSpeed}) applied globally. The compression test already sends the right header so it'll just work, and the other endpoints won't compress since wrk doesn't send Accept-Encoding by default.

Quick sanity check — should I also remove the manual Content-Encoding header setting in the compression handler, or just strip the whole manual implementation and let the middleware own the full pipeline?

doesnt the framework add the header automatically?

[BennyFranciscus]

Yeah, Fiber's compress middleware handles that automatically — it sets Content-Encoding based on what it negotiates from Accept-Encoding. So we just strip out the manual header setting along with the manual writers. The middleware owns the whole pipeline at that point.

I'll make sure the PR removes all the manual compression logic cleanly.

[Kaliumhexacyanoferrat]

we should go with the framework knowing when to compress given that the client sent the Accept-Encoding: gzip - that's how it should be

Agreed - yet if a framework natively supports compression on a specific path it should be allowed as well.

[BennyFranciscus]

Yeah, totally fair — if a framework has a documented way to scope compression to a specific route (like Fiber's route groups or a Next callback), that should be fine too. The key thing the audit rule cares about is "use the framework's own API" rather than "must be global middleware." Whether it's global with Accept-Encoding negotiation or scoped to /compression via a route group, both are using Fiber's compression middleware rather than raw stdlib writers.

The PR (#222) went with global registration since MDA2AV preferred letting the framework handle it via Accept-Encoding detection, but for other frameworks where per-path compression is the idiomatic approach, that's equally valid.

[Kaliumhexacyanoferrat]

Hm, thinking about this this is quite Hard. It should be configured like people will configure compression by default for the Framework. So if default is global then we should rather use global?

[BennyFranciscus]

Yeah, that's a good principle — configure it the way the framework's own docs recommend. For Fiber, the getting-started docs show app.Use(compress.New()) globally, so global makes sense there. For something like GenHTTP where you'd scope it to a handler or layout, per-route is the idiomatic approach.

The benchmark should reflect how real users would set it up, not force every framework into the same pattern. As long as it's using the framework's own compression API (not raw stdlib), the exact scoping should follow the framework's conventions.

[Kaliumhexacyanoferrat]

Well I kindly disagree - while GenHTTP easily supports compression on route level it is not the default configuration.

[BennyFranciscus]

Ah fair enough — I shouldn't have assumed GenHTTP's default is per-route just because it supports it. If global is the standard way people configure compression in GenHTTP, then global it is. Same principle applies across the board: just do what the framework docs show as the default setup.