8000 Allow rules to "block" requests from further processing by mrheinen · Pull Request #197 · mrheinen/lophiid · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Allow rules to "block" requests from further processing #197

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

Merged
merged 3 commits into from
May 19, 2025
Merged

Allow rules to "block" requests from further processing #197

merged 3 commits into from
May 19, 2025

Conversation

mrheinen
Copy link
Owner

Some requests are just not interesting but come in large amounts. Many bruteforce attacks are like this. They can be managed with the ratelimiting but when the last for a long time there will still be a significant amount of requests that makes it to the database and they just consume space.

By selecting the "block" checkbox in the rule you will now cause the backend to drop any further processing of a request when it matches that rule.

Copy link

Failed to generate code suggestions for PR

@mrheinen
Copy link
Owner Author

/windsurf-review

Copy link
@windsurf-bot windsurf-bot bot left a comment

Choose a reason for hiding this comment

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

Other comments: 0 Blocking, 0 Optional, 0 Nit, 1 FYI
  • FYI: pkg/agent/http_server.go (201-201) FYI: The HTTP status code for ResourceExhausted has been changed from 404 (Not Found) to 503 (Service Unavailable), which is more semantically correct for resource exhaustion scenarios.

Comment on lines +215 to +217
// Verify status code is 200 - OK (for non-status errors)
if res.StatusCode != http.StatusOK {
t.Errorf("expected status code %d, got %d", http.StatusOK, res.StatusCode)
Copy link

Choose a reason for hiding this comment

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

In TestCatchAllNonStatusError, returning HTTP 200 OK for a non-status error seems problematic. This suggests to clients that the request succeeded when in fact there was an error. Consider whether non-status errors should return an appropriate error code (like 500 Internal Server Error) instead.

@mrheinen mrheinen merged commit bd8ffee into main May 19, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
0