fix(middleware): gzip Write must return len(b), not the buffer length

[ultramcu]

Issue

middleware.gzipResponseWriter.Write violates the io.Writer contract. When a buffered write crosses MinLength, it flushes the whole buffer and returns the buffer length:

return w.Writer.Write(w.buffer.Bytes())

Because the buffer also holds bytes from earlier (sub-MinLength) writes, the returned n can exceed len(b). The io.Writer contract requires 0 <= n <= len(b), and consumers that validate this panic.

In particular io.Copy — which echo.Context#Stream uses internally (io.Copy(c.Response(), r)) — panics with:

bytes.Reader.WriteTo: invalid Write count

So streaming a response through the Gzip middleware crashes the request whenever a small write was buffered before the threshold-crossing write.

Fix

Flush the buffer as before, but report only len(b) (the bytes accepted from this call):

if _, err := w.Writer.Write(w.buffer.Bytes()); err != nil {
    return 0, err
}
return n, nil

n is already len(b) from the preceding w.buffer.Write(b).

Tests

Added middleware/compress_writecount_test.go:

• TestGzipWriteReturnsCorrectCount — Write reports len(b), never the buffered total.
• TestGzipIoCopyDoesNotPanic — streaming through gzip with io.Copy no longer panics.

Both fail on master (the second panics with invalid Write count) and pass with the fix. Existing compress tests (incl. TestGzipWithMinLengthChunked) and the full suite stay green under go test -race ./....

[aldas]

please rebase your PR

[ultramcu]

Thanks @aldas — done. I retargeted the PR to the v4 branch and rebased: the branch now sits directly on top of the current v4 tip (25685e6), a single commit, and GitHub shows it mergeable/clean. (The original mismatch was that it was opened against master, which is now the v5 module — the fix and test target v4.) Ready for review when you have a moment.