-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
grpc_json_transcoder: Adhere to decoder and encoder buffer limits #14906
grpc_json_transcoder: Adhere to decoder and encoder buffer limits #14906
Conversation
source/extensions/filters/http/grpc_json_transcoder/json_transcoder_filter.cc
Show resolved
Hide resolved
@@ -530,6 +534,9 @@ Http::FilterDataStatus JsonTranscoderFilter::decodeData(Buffer::Instance& data, | |||
} | |||
} else { | |||
request_in_.move(data); | |||
if (checkIfDecoderBufferLimitReached(request_in_.BytesStored())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not very accurate. incoming request bytes are converted on the flight to proto. It is stored here if I read it correctly.
We may have to count its size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Will spend some time evaluating if there are any other buffers internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a look at the transcoder library. This will only be a problem for the streaming cases. If two streaming messages occur in succession, then the byte limit will be inaccurate and the buffered data will exceed the allowed limit. This should be rare.
For unary request/response, the current implementation works for all cases. The buffer limit is checked before the message reaches any of those internal buffers. So the size unary messages will be counted correctly.
I would like to move forward with this PR and follow-up later. The diff is getting large. I am not worried about introducing a partial implementation here. There is never a case where the transcoder will incorrectly reject a request. It will always count the correct buffer usage or (in the streaming case) undercount buffer usage.
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
4bd75e7
to
5ce7e0a
Compare
… limit Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
Signed-off-by: Teju Nareddy <[email protected]>
What does [DNS] refer to in the PR title? |
Signed-off-by: Teju Nareddy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@snowp or @mattklein123 would one of you be up for final pass?
I can take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, LGTM with small comments.
/wait
source/extensions/filters/http/grpc_json_transcoder/json_transcoder_filter.cc
Show resolved
Hide resolved
Signed-off-by: Teju Nareddy <[email protected]>
CI will fail until #15075 is merged. |
Signed-off-by: Teju Nareddy <[email protected]>
/retest |
Retrying Azure Pipelines: |
Signed-off-by: Teju Nareddy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks LGTM with small comment.
/wait
source/extensions/filters/http/grpc_json_transcoder/json_transcoder_filter.cc
Outdated
Show resolved
Hide resolved
This reverts commit 5be2a1e Signed-off-by: Teju Nareddy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Commit Message:
grpc_json_transcoder: Adhere to decoder and encoder buffer limits
Additional Description:
Currently, the transcoder has unbounded internal buffering. This is not allowed according to the Extension stability and security posture.
This PR introduces limits to internal request/response buffers. This follows the documentation for Flow Control, but the filter does not participate in watermarking. Flow control via watermarking will not help the filter: Data stuck in a buffer will never be transcoded until more data comes in. If watermarking occurs, then the data will be stuck forever. So we fail the request with
HTTP 413
orHTTP 500
instead.Note: The current implementation does not handle some edge cases with streaming requests/responses. Those will require special handling. I will make a follow-up PR for that. See review comments for more details.
Risk Level:
Medium.
true
by default:envoy.reloadable_features.grpc_json_transcoder_adhere_to_buffer_limits
Testing:
Docs Changes: None
Release Notes: Yes
Platform Specific Features: None