Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>🐛 [Bug]: Compress middleware's shouldSkip method reads the entire payload into memory while streaming data</issue_title>
<issue_description>### Bug Description

The middleware/compress middleware in Fiber v3 reads the entire response body into memory before deciding whether to compress, even for streaming responses set via c.SendStream() / Response.SetBodyStream(). This defeats streaming and produces unbounded memory growth proportional to the response size.

The trigger is the shouldSkip helper introduced in #3745, specifically the len(c.Response().Body()) == 0 check:

// middleware/compress/compress.go
func shouldSkip(c fiber.Ctx) bool {
    if c.Method() == fiber.MethodHead {
        return true
    }
    status := c.Response().StatusCode()
    if status < 200 ||
        status == fiber.StatusNoContent ||
        status == fiber.StatusResetContent ||
        status == fiber.StatusNotModified ||
        status == fiber.StatusPartialContent ||
        len(c.Response().Body()) == 0 ||                       // <-- this line
        c.Get(fiber.HeaderRange) != "" ||
        hasToken(c.Get(fiber.HeaderCacheControl), "no-transform") ||
        hasToken(c.GetRespHeader(fiber.HeaderCacheControl), "no-transform") {
        return true
    }
    return false
}

In fasthttp, Response.Body() materializes any active bodyStream into the in-memory bodyBuffer via copyZeroAlloc:

// https://github.com/valyala/fasthttp/blob/v1.58.0/http.go#L411-L422
func (resp *Response) Body() []byte {
    if resp.bodyStream != nil {
        bodyBuf := resp.bodyBuffer()
        bodyBuf.Reset()
        _, err := copyZeroAlloc(bodyBuf, resp.bodyStream)
        resp.closeBodyStream(err)
        ...
    }
    return resp.bodyBytes()
}

So a handler that does c.SendStream(s3Body, contentLength) for a large object will have its entire payload pulled into RAM the moment shouldSkip runs.

How to Reproduce

1. Build the minimal program below and run with a soft memory cap so the impact is visible:

   GOMEMLIMIT=256MiB go run main.go
   

2. From another terminal, request a 512 MiB streamed payload — no Accept-Encoding header is needed:

   curl -sS --output /dev/null http://localhost:8080/file/512
   

3. Observe the server's memory ticker: HeapAlloc climbs to ~1 GiB (≈ 2× the payload size due to bytebufferpool reallocations during growth) and Sys grows to ~2 GiB.

4. As a control, change app.Use(compress.New()) to a no-op and re-run: HeapAlloc stays flat at ~1 MiB for the same 512 MiB streamed response.

In a memory-capped container (docker run -m 512m …), the kernel OOMKills the process on step 2.

Expected Behavior

Streaming responses set via c.SendStream / Response.SetBodyStream should pass through the compress middleware without being materialized into memory.

Fiber Version

v3.2.0

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have checked for existing issues that describe my problem prior to opening this one.
• I understand that improperly formatted bug reports may be closed without explanation.</issue_description>

Comments on the Issue (you are @claude[agent] in this section)