🐛 bug: Fix Range() handling of HTTP 416 per RFC 9110#3552
Conversation
|
Warning Rate limit exceeded@gaby has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 37 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThe Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant FiberCtx
participant Resource
Client->>FiberCtx: GET /resource (with Range header)
FiberCtx->>Resource: Check resource size
FiberCtx->>FiberCtx: Parse Range header
alt Range satisfiable
FiberCtx->>Client: Respond with partial content (206)
else Range unsatisfiable
FiberCtx->>Client: Set status 416, Content-Range: bytes */<size>
end
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Pull Request Overview
This PR aligns Range handling with RFC 9110 by automatically responding with a 416 status and populating the Content-Range header when no requested ranges are satisfiable.
- Auto-sets HTTP 416 status and
Content-Rangeheader inRange() - Updates documentation to describe the automatic 416 behavior
- Adds a test (
Test_Ctx_Range_Unsatisfiable) verifying the 416 response
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| docs/api/ctx.md | Document automatic 416 Range Not Satisfiable handling |
| ctx.go | Implement status/header setting and return error for unsatisfiable ranges |
| ctx_test.go | Add test to verify 416 response and Content-Range for unsatisfiable range |
Comments suppressed due to low confidence (3)
ctx.go:1389
- [nitpick] The error variable ErrRequestedRangeNotSatisfiable is verbose and may be confusing; consider renaming it to ErrRangeNotSatisfiable to align with existing ErrRangeUnsatisfiable and the HTTP status constant.
return rangeData, ErrRequestedRangeNotSatisfiable
docs/api/ctx.md:1219
- The docs mention automatic status and header settings but do not specify that the method returns ErrRequestedRangeNotSatisfiable; consider documenting the error return for clarity.
If none of the requested ranges are satisfiable, the method automatically
ctx_test.go:2998
- The test verifies status code and header but does not assert that Range returns ErrRequestedRangeNotSatisfiable; consider adding an assertion like
require.ErrorIs(t, err, ErrRequestedRangeNotSatisfiable)to fully validate the behavior.
_, err := c.Range(10)
There was a problem hiding this comment.
Summary of Changes
Hello @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 enhances the Range() function to automatically handle unsatisfiable range requests by sending a 416 status code and setting the Content-Range header, as per RFC 9110. It also includes documentation updates and a new test case to ensure the correct behavior.
Highlights
- RFC 9110 Compliance: The PR ensures that a 416 status code is automatically sent when a range request is unsatisfiable, aligning with RFC 9110.
- Automatic 416 Handling: The
Range()function now automatically handles the 416 status, improving the developer experience. - Testing: Added a new test case to specifically verify the 416 Range Not Satisfiable response.
- Documentation: Updated the documentation for the
Range()function to reflect the automatic 416 handling.
Using Gemini Code Assist
The 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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and 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 to provide feedback.
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
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3552 +/- ##
=======================================
Coverage 91.02% 91.02%
=======================================
Files 110 110
Lines 10955 10957 +2
=======================================
+ Hits 9972 9974 +2
Misses 731 731
Partials 252 252
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/api/ctx.md (1)
1219-1221: ClarifyContent-Rangeheader formatRFC 9110 §14.4 requires the header value for a 416 response to be
Content-Range: bytes */<complete-length>.
Spelling this out (e.g., “Content-Range: bytes */1234”) or linking to the
relevant section would remove any ambiguity for readers implementing clients
or middleware that validate the header.No functional issue—purely a doc precision tweak.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
ctx.go(1 hunks)ctx_test.go(1 hunks)docs/api/ctx.md(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: ReneWerner87
PR: gofiber/fiber#0
File: :0-0
Timestamp: 2024-12-01T10:28:36.011Z
Learning: Feature request #3224 has been created to add support for square bracket notation and comma-separated values in multipart form data in Fiber, while maintaining binary data transfer capabilities. This would bring parity with the existing form-urlencoded functionality.
Learnt from: ReneWerner87
PR: gofiber/fiber#0
File: :0-0
Timestamp: 2024-12-01T10:28:36.011Z
Learning: Fiber currently supports square bracket notation in form data with 'application/x-www-form-urlencoded' content type, but this feature is not available for multipart form data. The implementation for form-urlencoded is in ctx.go (BodyParser method), while multipart form data handling needs enhancement to support this feature.
Learnt from: ReneWerner87
PR: gofiber/fiber#3161
File: app.go:923-932
Timestamp: 2024-11-15T07:56:21.623Z
Learning: In the Fiber framework, breaking changes are acceptable when moving from version 2 to version 3, including modifications to method signatures such as in the `Test` method in `app.go`.
Learnt from: sixcolors
PR: gofiber/fiber#3446
File: docs/middleware/logger.md:44-44
Timestamp: 2025-05-13T00:19:16.407Z
Learning: In documentation files for the Fiber framework, code examples are often partial and don't repeat import statements that were shown in earlier examples, focusing instead on demonstrating specific usage patterns.
docs/api/ctx.md (5)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: ReneWerner87
PR: gofiber/fiber#3161
File: app.go:923-932
Timestamp: 2024-11-15T07:56:21.623Z
Learning: In the Fiber framework, breaking changes are acceptable when moving from version 2 to version 3, including modifications to method signatures such as in the `Test` method in `app.go`.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/csrf/csrf_test.go:188-193
Timestamp: 2024-09-25T15:57:10.221Z
Learning: In the Fiber framework tests, using `ctx.Response.Header.Cookie` may not be suitable for parsing cookies from the response header, as it requires a `*Cookie` and fills it rather than returning a string value; thus, manual parsing of the `Set-Cookie` header may be necessary.
Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/csrf/csrf_test.go:188-193
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the Fiber framework tests, using `ctx.Response.Header.Cookie` may not be suitable for parsing cookies from the response header, as it requires a `*Cookie` and fills it rather than returning a string value; thus, manual parsing of the `Set-Cookie` header may be necessary.
ctx.go (2)
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.
Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.
ctx_test.go (14)
undefined
<retrieved_learning>
Learnt from: ReneWerner87
PR: #3161
File: app.go:923-932
Timestamp: 2024-11-15T07:56:21.623Z
Learning: In the Fiber framework, breaking changes are acceptable when moving from version 2 to version 3, including modifications to method signatures such as in the Test method in app.go.
</retrieved_learning>
<retrieved_learning>
Learnt from: gaby
PR: #3170
File: ctx_test.go:1721-1724
Timestamp: 2024-10-16T12:12:30.506Z
Learning: In the Go unit tests in ctx_test.go, it is acceptable to use invalid CIDR notation such as "0.0.0.1/31junk" for testing purposes.
</retrieved_learning>
<retrieved_learning>
Learnt from: gaby
PR: #3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the middleware/adaptor/adaptor.go file of the Fiber framework, when updating context handling, replacing c.Context() with c.RequestCtx() is appropriate to access the fasthttp.RequestCtx.
</retrieved_learning>
<retrieved_learning>
Learnt from: efectn
PR: #3162
File: app_test.go:893-895
Timestamp: 2024-11-29T12:37:27.581Z
Learning: In the Test_App_ShutdownWithContext function in app_test.go, the clientDone channel is used to synchronize the client's request completion before proceeding, eliminating the need for additional time.Sleep calls.
</retrieved_learning>
<retrieved_learning>
Learnt from: gaby
PR: #3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, Context() is being renamed to RequestCtx(), and UserContext() to Context() to improve clarity and align with Go's context conventions.
</retrieved_learning>
<retrieved_learning>
Learnt from: sixcolors
PR: #3016
File: middleware/csrf/csrf_test.go:188-193
Timestamp: 2024-09-25T15:57:10.221Z
Learning: In the Fiber framework tests, using ctx.Response.Header.Cookie may not be suitable for parsing cookies from the response header, as it requires a *Cookie and fills it rather than returning a string value; thus, manual parsing of the Set-Cookie header may be necessary.
</retrieved_learning>
<retrieved_learning>
Learnt from: sixcolors
PR: #3016
File: middleware/csrf/csrf_test.go:188-193
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In the Fiber framework tests, using ctx.Response.Header.Cookie may not be suitable for parsing cookies from the response header, as it requires a *Cookie and fills it rather than returning a string value; thus, manual parsing of the Set-Cookie header may be necessary.
</retrieved_learning>
<retrieved_learning>
Learnt from: gaby
PR: #3056
File: middleware/encryptcookie/utils.go:22-25
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The encryptcookie_test.go file contains unit tests that validate key lengths for both EncryptCookie and DecryptCookie functions, ensuring that invalid key lengths raise appropriate errors.
</retrieved_learning>
<retrieved_learning>
Learnt from: gaby
PR: #3056
File: middleware/encryptcookie/utils.go:22-25
Timestamp: 2024-07-02T13:29:56.992Z
Learning: The encryptcookie_test.go file contains unit tests that validate key lengths for both EncryptCookie and DecryptCookie functions, ensuring that invalid key lengths raise appropriate errors.
</retrieved_learning>
<retrieved_learning>
Learnt from: sixcolors
PR: #2922
File: middleware/cors/utils.go:63-71
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The project uses the testify/assert package for assertions in unit tests.
</retrieved_learning>
<retrieved_learning>
Learnt from: sixcolors
PR: #3016
File: middleware/session/store.go:164-167
Timestamp: 2024-10-02T23:03:31.727Z
Learning: Unit tests in this project use testify require.
</retrieved_learning>
<retrieved_learning>
Learnt from: sixcolors
PR: #3016
File: middleware/session/store.go:164-167
Timestamp: 2024-10-08T19:06:06.583Z
Learning: Unit tests in this project use testify require.
</retrieved_learning>
<retrieved_learning>
Learnt from: sixcolors
PR: #2922
File: middleware/cors/utils.go:63-71
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The project uses the testify/assert package for assertions in unit tests.
</retrieved_learning>
<retrieved_learning>
Learnt from: efectn
PR: #3162
File: hooks_test.go:228-228
Timestamp: 2024-12-13T08:14:22.851Z
Learning: In Go test files, prefer using the require methods from the testify package for assertions instead of manual comparisons and calls to t.Fatal or t.Fatalf.
</retrieved_learning>
🧬 Code Graph Analysis (1)
ctx.go (1)
constants.go (3)
StatusRequestedRangeNotSatisfiable(87-87)HeaderContentRange(232-232)ErrRequestedRangeNotSatisfiable(132-132)
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: unit (1.24.x, macos-13)
- GitHub Check: unit (1.24.x, macos-latest)
- GitHub Check: unit (1.24.x, windows-latest)
- GitHub Check: Compare
- GitHub Check: repeated
- GitHub Check: Analyse
🔇 Additional comments (2)
ctx.go (1)
1387-1389: LGTM! Excellent RFC 9110 compliance implementation.The automatic 416 status code handling is correctly implemented:
- ✅ Sets
StatusRequestedRangeNotSatisfiable(416) status code when no valid ranges are found- ✅ Includes the required
Content-Range: bytes */{size}header per RFC 9110 specification- ✅ Returns
ErrRequestedRangeNotSatisfiableerror for proper error handling- ✅ Maintains backward compatibility by still returning range data
This change properly aligns Fiber's range handling with HTTP standards while following the framework's existing patterns.
ctx_test.go (1)
2994-3011: LGTM! Well-written test for unsatisfiable range handling.This test correctly verifies the new automatic 416 status code behavior for unsatisfiable range requests as described in the PR objectives. The test logic is sound:
- Requests bytes 20-30 from a 10-byte resource (clearly unsatisfiable)
- Properly validates the 416 status code response
- Checks the correct Content-Range header format "bytes */10"
The test follows Go testing best practices and is consistent with the project's testing patterns using testify/require.
There was a problem hiding this comment.
Code Review
This pull request enhances the handling of unsatisfiable range requests by automatically setting the 416 status code and Content-Range header, aligning with RFC 9110. The changes include updating the Range() method, adding a test case, and documenting the new behavior. A suggestion has been made to improve performance by using strconv.Itoa instead of fmt.Sprintf.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
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: 7ddadae | Previous: 55818fb | Ratio |
|---|---|---|---|
Benchmark_Ctx_SendString_B |
15.57 ns/op 0 B/op 0 allocs/op |
9.658 ns/op 0 B/op 0 allocs/op |
1.61 |
Benchmark_Ctx_SendString_B - ns/op |
15.57 ns/op |
9.658 ns/op |
1.61 |
This comment was automatically generated by workflow using github-action-benchmark.
Summary
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/416
Related #3383