Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds support to restrict HTTP response sizes #23440

Merged
merged 6 commits into from
Jan 6, 2025

Conversation

dhr-verma
Copy link
Contributor

@dhr-verma dhr-verma commented Jan 3, 2025

Description

This PR adds a new module - ResponseSizeMiddleware. This class has a method to validate response sizes to ensure that their byte sizes is below a given a maxResponseSizeInMegaBytes. If the response body is greater than maxResponseSizeInMegaBytes, an HTTP 413 is sent as a response, else the original response is sent back to the client. This is introduced to primarily enforce response sizes in the storage stack (Historian and Gitrest). A future PR will add this module to both Gitrest and Historian after the r11 changes are merged.

Historian and Gitrest both have request size limitations. Hence, this PR just adds support to limit response sizes. This is added to reduce the chances of Gitrest returning very large responses that could result in Historian running OOM.

@github-actions github-actions bot added the area: server Server related issues (routerlicious) label Jan 3, 2025
@dhr-verma dhr-verma requested a review from manishgargd January 3, 2025 17:44
@github-actions github-actions bot added the base: main PRs targeted against main branch label Jan 3, 2025
Copy link
Contributor

@Copilot 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.

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

server/routerlicious/packages/services-utils/src/responseSizeMiddleware.ts:18

  • [nitpick] The error message 'Invalid JSON string in response body' could be more descriptive. Consider changing it to 'Response body is not a valid JSON string'.
Lumberjack.error("Invalid JSON string in response body");

// eslint-disable-next-line @typescript-eslint/no-misused-promises
return async (req, res, next) => {
const originalSend = res.send;
res.send = (body) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks good overall! One small suggestion is to try not to mutate res.send if possible. I am not sure if there are easy ways to do that, but if there are it might be worth considering.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay lemme look into more implementations

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was unable to find a way to carry out this operation without mutating the send object. However, most SO posts seem to suggest this approach

@dhr-verma dhr-verma merged commit e703479 into microsoft:main Jan 6, 2025
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: server Server related issues (routerlicious) base: main PRs targeted against main branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants