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

Add log_client_closures http option #397

Merged
merged 3 commits into from
Sep 17, 2024
Merged

Conversation

goncalotomas
Copy link
Contributor

Created as a result from this discussion
This PR adds a new http option, log_client_closures, that allows users to silence Bandit.HTTP errors that stem from clients closing the connection. The option defaults to false.

@@ -2150,7 +2183,7 @@ defmodule HTTP1RequestTest do

assert output =~ "(Bandit.HTTPError) closed"
refute output =~ "IMPOSSIBLE"
assert ThousandIsland.connection_pids(context.server_pid) == {:ok, []}
assert ThousandIsland.connection_pids(context[:server_pid]) == {:ok, []}
Copy link
Contributor Author

@goncalotomas goncalotomas Sep 14, 2024

Choose a reason for hiding this comment

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

I had to add this because I believe the http_server functionat the beginning of the test convertscontext` from a map into a keyword list. I was getting the following error, so I had to make this change:

** (KeyError) key :server_pid not found in: [base: "http://localhost:35985", port: 35985, server_pid: #PID<0.531.0>]

     If you are using the dot syntax, such as map.field, make sure the left-hand side of the dot is a map

@@ -2159,6 +2192,7 @@ defmodule HTTP1RequestTest do
end

test "raises an error if client closes while body is being written", context do
context = http_server(context, http_options: [log_client_closures: true])
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'm turning on the option here because we assert that the error happened by capturing the logs, so we need to log the closure in these existing tests.

@goncalotomas
Copy link
Contributor Author

@mtrudel I ended up not being able to test the HTTP2 part, let me know if you can think of a way to test this, and feel free to add changes.

@mtrudel
Copy link
Owner

mtrudel commented Sep 16, 2024

Refactored the implementation to be shared (I've been meaning to do that for a while anyway!) and added some docs.

Pending your approval of these changes we can get this merged!

@goncalotomas
Copy link
Contributor Author

I can only see my single commit in this PR, not sure if you've pushed your changes?

I approve whichever changes you feel are appropriate to get this merged, so feel free to push + merge :)

Thank you!

@mtrudel
Copy link
Owner

mtrudel commented Sep 17, 2024

Huh, you're right - GitHub didn't allow me to push the changes up. Did you enable 'allow edits' per https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork?

@goncalotomas
Copy link
Contributor Author

That option was preselected, it was enabled when I submitted the PR and it looks like it still is:
image
I'll try disabling and re-enabling the option, but I don't know why this happened. 😕

@goncalotomas
Copy link
Contributor Author

I've done the disable / re-enable thing on the checkbox, plus I've invited you as a collaborator on my fork to see if that fixes it. I've done a couple of PRs after forking a repo and I've never had this issue before 🤔

@mtrudel
Copy link
Owner

mtrudel commented Sep 17, 2024

I've done a couple of PRs after forking a repo and I've never had this issue before 🤔

It seems to happen about 25% of the time, not entirely sure why.

In any case, i seem to have messed it up even worse 😠

@mtrudel mtrudel reopened this Sep 17, 2024
@mtrudel
Copy link
Owner

mtrudel commented Sep 17, 2024

Eesh. Fixed now, ready for review.

@goncalotomas
Copy link
Contributor Author

Good call making this new option have the same values as log_protocol_errors! I struggled to decide whether or not to make it a simple boolean option but I agree this is more consistent with the existing behaviour.

The docs bit completely slipped my mind 😅
Looks good to me, feel free to merge!

@mtrudel mtrudel merged commit 55ac87a into mtrudel:main Sep 17, 2024
51 of 56 checks passed
@mtrudel
Copy link
Owner

mtrudel commented Sep 17, 2024

Thanks for the PR! I'm going to bundle this with a few other pending / recent changes and do a release this coming weekend.

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.

2 participants