Skip to content

🐛 bug: Fix math.MaxUint32 overflow in etag middleware on 32-bit platforms#4135

Merged
ReneWerner87 merged 2 commits intomainfrom
copilot/fix-etag-issue-on-32-bit
Mar 9, 2026
Merged

🐛 bug: Fix math.MaxUint32 overflow in etag middleware on 32-bit platforms#4135
ReneWerner87 merged 2 commits intomainfrom
copilot/fix-etag-issue-on-32-bit

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Mar 9, 2026

On 32-bit platforms, int is 32-bit and cannot represent the untyped constant math.MaxUint32 (4,294,967,295). The comparisons len(body) > math.MaxUint32 in the etag middleware caused a compile-time error on 32-bit targets, breaking any app using the compress middleware (which depends on etag).

Changes introduced

  • middleware/etag/etag.go: Cast len(body) to uint64 before comparing with math.MaxUint32 in both Generate and the New handler. uint64 holds the constant on all platforms; on 32-bit, len() can never exceed math.MaxInt32 < math.MaxUint32 so the check is always false (correct behavior preserved).
// Before — compile error on GOARCH=386
if len(body) > math.MaxUint32 { ... }

// After — compiles and works correctly on all platforms
if uint64(len(body)) > math.MaxUint32 { ... }
  • Benchmarks: N/A — no hot path change; the guard condition result is identical on 64-bit.
  • Documentation Update: No documentation changes required.
  • Changelog/What's New: Fix 32-bit build failure in etag middleware (GOARCH=386, GOARCH=arm, etc.).
  • Migration Guide: No migration needed.
  • API Alignment with Express: N/A
  • API Longevity: N/A
  • Examples: N/A

Type of change

  • Code consistency (non-breaking change which improves code reliability and robustness)

Checklist

  • Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
  • Conducted a self-review of the code and provided comments for complex or critical parts.
  • Updated the documentation in the /docs/ directory for Fiber's documentation.
  • Added or updated unit tests to validate the effectiveness of the changes or new features.
  • Ensured that new and existing unit tests pass locally with the changes.
  • Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
  • Aimed for optimal performance with minimal allocations in the new code.
  • Provided benchmarks for the new code to analyze and improve upon.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • exampleretry.com
    • Triggering command: /tmp/go-build1732996263/b307/client.test /tmp/go-build1732996263/b307/client.test -test.paniconexit0 -test.v=test2json -test.timeout=10m0s -test.count=1 -test.shuffle=on 0.1-go1.25.0.linux-amd64/src/runcrypto/sha256 ux-amd64/pkg/tool/linux_amd64/vet -d main l/linux_amd64/co-unreachable=false ux-amd64/pkg/too/tmp/go-build1732996263/b102/vet.cfg -V=f�� aiJC5TRFccldbcSaLaNp/aiJC5TRFccl-p l/linux_amd64/compile ux-amd64/pkg/tool/linux_amd64/vet -c=4 -nolocalimports -importcfg ux-amd64/pkg/too-buildtags (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Original prompt

This section details on the original issue you should resolve

<issue_title>🐛 [Bug]: Compiling on 32 bits platforms using etag middleware fails with math.MaxUint32 (untyped int constant 4294967295) overflows int</issue_title>
<issue_description>### Bug Description

The compress middleware depends on Fiber’s etag package to recompute strong ETags after compressing the response body. That etag code uses math.MaxUint32, which overflows int on 32-bit, crashing with an math.MaxUint32 (untyped int constant 4294967295) overflows int error.
Currently the only solution I've found is conditional compilation with build tags, avoiding the compress dependency (which in turn uses etag) on building binaries targeted to 32 bit systems.
There was already a PR trying to fix this which was closed: #3469

How to Reproduce

Steps to reproduce the behavior:

  1. Try to build an app using the compress middleware to a 32 bit executable.

Expected Behavior

The Fiber app using the compress middleware should build with no errors 32 bit apps.

Fiber Version

v3.1.0

Code Snippet (optional)

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 @copilot in this section)


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copilot AI changed the title [WIP] Fix etag middleware overflow issue on 32-bit platforms 🐛 bug: Fix math.MaxUint32 overflow in etag middleware on 32-bit platforms Mar 9, 2026
@ReneWerner87 ReneWerner87 added this to the v3 milestone Mar 9, 2026
@ReneWerner87 ReneWerner87 added this to v3 Mar 9, 2026
@codecov
Copy link
Copy Markdown

codecov Bot commented Mar 9, 2026

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.10%. Comparing base (c493e59) to head (64afe29).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
middleware/etag/etag.go 0.00% 0 Missing and 2 partials ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #4135   +/-   ##
=======================================
  Coverage   91.10%   91.10%           
=======================================
  Files         119      119           
  Lines       11385    11385           
=======================================
  Hits        10372    10372           
  Misses        642      642           
  Partials      371      371           
Flag Coverage Δ
unittests 91.10% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@gaby
Copy link
Copy Markdown
Member

gaby commented Mar 9, 2026

@copilot we probably have to cast MaxUint32 by doing;

uint32(math.MaxUint32)

Copy link
Copy Markdown
Contributor Author

Copilot AI commented Mar 9, 2026

@copilot we probably have to cast MaxUint32 by doing;

uint32(math.MaxUint32)

Using uint32(math.MaxUint32) alone wouldn't work here because Go doesn't allow comparing int (from len()) with uint32 directly — it's a type mismatch. And wrapping it further with int(uint32(math.MaxUint32)) still fails to compile on 32-bit since the constant 4294967295 overflows int at compile time.

The uint64(len(body)) > math.MaxUint32 approach works because uint64 can hold both values on all platforms. On 32-bit, len() can never exceed MaxInt32 (< MaxUint32), so the check is always false — correct behavior. On 64-bit, it works as before.

Happy to change the approach if you have a different preference in mind though!

Copilot finished work on behalf of gaby March 9, 2026 11:47
@gaby
Copy link
Copy Markdown
Member

gaby commented Mar 9, 2026

@copilot Please review the codebase to determine if this fix needs to be applied elsewhere.

Copy link
Copy Markdown
Contributor Author

Copilot AI commented Mar 9, 2026

@copilot Please review the codebase to determine if this fix needs to be applied elsewhere.

I searched the entire codebase for math.MaxUint32, math.MaxUint64, math.MaxInt64, and math.MaxUint16 usage. Here's what I found:

  • helpers_test.gomath.MaxUint32 is stored in a uint64-typed struct field. No issue.
  • middleware/cache/cache_test.gomath.MaxUint32 in a []uint{...} literal. Safe because uint is unsigned and can hold MaxUint32 even on 32-bit.
  • middleware/cache/cache.go and middleware/limiter/limiter_sliding.go — use math.MaxInt64 with int64/uint64/time.Duration types. Safe.
  • req.go and ctx_test.go — use math.MaxUint64 with explicit uint64 types. Safe.

I also verified the full build compiles cleanly on 32-bit: GOARCH=386 go build ./... and GOARCH=386 go test -run=^$ ./... both pass with zero errors. The only place that had the overflow issue was middleware/etag/etag.go, which is already fixed in this PR.

Copilot finished work on behalf of gaby March 9, 2026 12:02
@gaby gaby marked this pull request as ready for review March 9, 2026 12:13
@gaby gaby requested a review from a team as a code owner March 9, 2026 12:13
@gaby gaby moved this to In Progress in v3 Mar 9, 2026
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a 32-bit build failure in the etag middleware caused by comparing len(body) (typed int) against math.MaxUint32 (untyped constant too large for 32-bit int). This keeps etag (and transitively compress) compiling and working on 32-bit GOARCH targets.

Changes:

  • Compare uint64(len(body))/uint64(bodyLength) to math.MaxUint32 in Generate and the New middleware handler to avoid 32-bit constant overflow.

@ReneWerner87 ReneWerner87 merged commit c3e30c5 into main Mar 9, 2026
31 of 32 checks passed
@ReneWerner87 ReneWerner87 deleted the copilot/fix-etag-issue-on-32-bit branch March 9, 2026 12:37
@github-project-automation github-project-automation Bot moved this from In Progress to Done in v3 Mar 9, 2026
@ReneWerner87 ReneWerner87 modified the milestones: v3, v3.2.0 Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

🐛 [Bug]: Compiling on 32 bits platforms using etag middleware fails with math.MaxUint32 (untyped int constant 4294967295) overflows int

4 participants