Fix handling of bad requests #29249
Merged
Fix handling of bad requests #29249
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Today we have a few problems with how we handle bad requests: - handling requests with bad encoding - handling requests with invalid value for filter_path/pretty/human - handling requests with a garbage Content-Type header There are two problems: - in every case, we give an empty response to the client - in most cases, we leak the byte buffer backing the request! These problems are caused by a broader problem: poor handling preparing the request for handling, or the channel to write to when the response is ready. This commit addresses these issues by taking a unified approach to all of them that ensures that: - we respond to the client with the exception that blew us up - we do not leak the byte buffer backing the request
jasontedor
added
>bug
review
:Distributed Coordination/Network
Collaborator
|
Pinging @elastic/es-core-infra |
Member
Author
|
retest this please |
* master: Do not optimize append-only if seen normal op with higher seqno (elastic#28787) [test] packaging: gradle tasks for groovy tests (elastic#29046) Prune only gc deletes below local checkpoint (elastic#28790)
Member
Author
|
@nik9000 @tbrooks8 This is ready for review now. 😌 |
nik9000
approved these changes
Mar 27, 2018
Member
nik9000
left a comment
nik9000
left a comment
There was a problem hiding this comment.
I don't know this code particularly well but it looks like an improvement to me. I think @tbrooks8 should also have a look. ❤️, thanks for fixing these! Leaking the byte buffer seems pretty bad!
Contributor
|
I'll take a look today, I'd held off as I kept seeing new commits. Thanks for the ping. |
Member
Author
Yeah sorry about all those pings. I was really unhappy with the first version of the PR when I woke up the next morning so had to push on it again to get it to a spot I was happy with. Thanks for reviewing. |
jasontedor
added a commit
that referenced
this pull request
Mar 28, 2018
Today we have a few problems with how we handle bad requests: - handling requests with bad encoding - handling requests with invalid value for filter_path/pretty/human - handling requests with a garbage Content-Type header There are two problems: - in every case, we give an empty response to the client - in most cases, we leak the byte buffer backing the request! These problems are caused by a broader problem: poor handling preparing the request for handling, or the channel to write to when the response is ready. This commit addresses these issues by taking a unified approach to all of them that ensures that: - we respond to the client with the exception that blew us up - we do not leak the byte buffer backing the request
Member
Author
|
Thanks for reviewing @nik9000 and @tbrooks8. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today we have a few problems with how we handle bad requests:
There are two problems:
These problems are caused by a broader problem: poor handling preparing the request for handling, or the channel to write to when the response is ready. This commit addresses these issues by taking a unified approach to all of them that ensures that:
Closes #21974, relates #28909