feat: Make request header and body size configurable#1892
feat: Make request header and body size configurable#1892marcozabel wants to merge 3 commits intoopen-feature:mainfrom
Conversation
Signed-off-by: marcozabel <marco.zabel@dynatrace.com>
Signed-off-by: marcozabel <marco.zabel@dynatrace.com>
✅ Deploy Preview for polite-licorice-3db33c ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Summary of ChangesHello, 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 Highlights
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
|
Signed-off-by: marcozabel <marco.zabel@dynatrace.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces configurability for request header and body sizes, which is a valuable feature for security and resource management. The implementation is solid, adding new flags, propagating the configuration, and applying the limits at the HTTP server level for both connect and OFREP services. The new tests effectively validate the behavior for oversized requests. I have one suggestion to refactor some duplicated error handling logic in the OFREP handler to improve maintainability.
| if err != nil { | ||
| var maxBytesErr *http.MaxBytesError | ||
| if errors.As(err, &maxBytesErr) { | ||
| w.WriteHeader(http.StatusRequestEntityTooLarge) | ||
| return | ||
| } | ||
| h.writeJSONToResponse(http.StatusBadRequest, ofrep.ContextErrorResponseFrom(flagKey), w) | ||
| return | ||
| } |
There was a problem hiding this comment.
This error handling block is nearly identical to the one in HandleBulkEvaluation on lines 121-129. To improve maintainability and adhere to the Don't Repeat Yourself (DRY) principle, this duplicated logic should be extracted into a shared helper function.
A helper function could handle checking for *http.MaxBytesError and other extraction errors, reducing code duplication and making the handlers cleaner.
For example:
// handleExtractionError checks for errors from extractOfrepRequest and writes an appropriate response.
// It returns true if an error was handled.
func (h *handler) handleExtractionError(w http.ResponseWriter, err error, errorPayload any) bool {
if err == nil {
return false
}
var maxBytesErr *http.MaxBytesError
if errors.As(err, &maxBytesErr) {
w.WriteHeader(http.StatusRequestEntityTooLarge)
return true
}
h.writeJSONToResponse(http.StatusBadRequest, errorPayload, w)
return true
}Using this helper would simplify both HandleFlagEvaluation and HandleBulkEvaluation.
|
1 participant
This PR
Related Issues
Fixes #1234523
Notes
Follow-up Tasks
How to test