🐛 bug: enforce Range header limit configuration#4071
Conversation
Summary of ChangesHello @gaby, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a potential resource exhaustion vulnerability by introducing a configurable limit on the number of ranges processed from an HTTP Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds Config.MaxRanges (default 16) and enforces it during Range header parsing; exceeding the limit returns HTTP 416 with a Content-Range header and ErrRangeTooLarge. Also adds docs, a test, an exported error, a small BasicAuth trimming change, and context doc-comment updates. Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant Ctx as Ctx.Range()
participant App as App.Config
participant Res as Response
Client->>Ctx: Request with Range header (multiple ranges)
Ctx->>App: read config.MaxRanges
Ctx->>Ctx: parse ranges, increment count
alt count <= MaxRanges
Ctx->>Ctx: finish parsing
Ctx->>Res: return ranges (206 or appropriate)
Res-->>Client: 206 Partial Content / response
else count > MaxRanges
Ctx->>Res: set Status 416 and header "Content-Range: bytes */<size>"
Res-->>Client: 416 Requested Range Not Satisfiable
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
No actionable comments were generated in the recent review. 🎉 Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4071 +/- ##
==========================================
- Coverage 91.08% 91.04% -0.05%
==========================================
Files 119 119
Lines 11221 11256 +35
==========================================
+ Hits 10221 10248 +27
- Misses 633 637 +4
- Partials 367 371 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Code Review
This pull request introduces a configurable limit for the number of ranges parsed from a Range header to prevent resource exhaustion attacks. The implementation is solid, adding a MaxRanges field to the Config struct, enforcing the limit in DefaultReq.Range(), and including corresponding tests and documentation. The changes are well-executed and improve the robustness of the framework. I have one minor suggestion to further optimize performance in the range parsing logic.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@docs/api/fiber.md`:
- Line 49: The table row for the configuration option `MaxRanges` is out of
alphabetical order; move the entire row describing `<Reference
id="maxranges">MaxRanges</Reference>` so it appears between the `Immutable` and
`MsgpackEncoder` rows (instead of between `BodyLimit` and `CaseSensitive`) to
restore alphabetical ordering of the config table in docs/api/fiber.md.
🧹 Nitpick comments (2)
req.go (1)
931-936: Minor: partialrangeData.Rangesis returned on over-limit.When the limit is exceeded mid-parse (e.g.,
maxRanges=2with 3 ranges), the returnedRangestruct will contain the ranges parsed before the cap was hit. Callers that checkerr != nilfirst will be fine, but callers that inspectrangeData.Rangesalongside the error could see a partially populated slice.This matches the existing behavior for
ErrRangeMalformed(lines 952, 960) which also returns a partially populatedrangeData, so it's consistent. Just something to be aware of.error.go (1)
33-37: Inconsistent error types within the Range errors block.
ErrRangeTooLargeusesNewError()(returning*fiber.Errorwith an HTTP status code), whileErrRangeMalformedandErrRangeUnsatisfiableuseerrors.New()(plainerror). This meanserrors.Is(err, ErrRangeTooLarge)will behave differently from the siblings — callers doing type-based error handling may be surprised.This is likely intentional since
ErrRangeTooLargeis designed to carry a 416 status for the error handler, but it's worth a brief comment explaining the distinction.
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.50.
| Benchmark suite | Current: b4ab278 | Previous: 6bbbc4a | Ratio |
|---|---|---|---|
Benchmark_Ctx_Range/bytes=500-1000 - B/op |
128 B/op |
16 B/op |
8 |
Benchmark_Ctx_Range/bytes=0-700,800-1000 - B/op |
128 B/op |
48 B/op |
2.67 |
This comment was automatically generated by workflow using github-action-benchmark.
There was a problem hiding this comment.
Pull request overview
This PR introduces a configurable cap on how many byte ranges are parsed from the Range header to reduce resource exhaustion risk and make the default behavior consistent via fiber.New() config normalization.
Changes:
- Add
Config.MaxRangeswithDefaultMaxRanges = 16and apply the default inNew()when the configured value is non-positive. - Enforce the configured maximum in
DefaultReq.Range()and return a newErrRangeTooLargewhile setting416andContent-Range: bytes */<size>when exceeded. - Update docs and tests to cover the new
MaxRangesbehavior (including an over-limit case).
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| req.go | Enforces the configured maximum number of parsed ranges and returns ErrRangeTooLarge when exceeded. |
| error.go | Introduces ErrRangeTooLarge as a first-class error for over-limit Range parsing. |
| app.go | Adds Config.MaxRanges, DefaultMaxRanges, and defaults MaxRanges in New(). |
| ctx_test.go | Adds a test that verifies a request is rejected with 416 when the range count exceeds MaxRanges. |
| docs/api/fiber.md | Documents the new MaxRanges config option and its behavior. |
| ctx_interface_gen.go | Updates generated interface comments related to released contexts returning nil. |

Motivation
Rangeheaders by capping the number of parsed ranges and make the configuration clearer and consistent across initialization and parsing.Description
Config.MaxRangeswithDefaultMaxRanges = 16and apply the default inNew()when the configured value is non-positive.DefaultReq.Range()by counting parsed ranges and returningErrRangeTooLargewhile setting status416andContent-Range: bytes */<size>when exceeded.ErrRangeTooLarge, update tests to cover the over-limit case, and documentMaxRangesindocs/api/fiber.md.DefaultReq.Range()so the code relies on the default applied inApp.New().