grpc_json_transcoder: Adhere to decoder and encoder buffer limits#14906
grpc_json_transcoder: Adhere to decoder and encoder buffer limits#14906mattklein123 merged 26 commits intoenvoyproxy:mainfrom
Conversation
source/extensions/filters/http/grpc_json_transcoder/json_transcoder_filter.cc
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
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.
Got it. Will spend some time evaluating if there are any other buffers internally.
There was a problem hiding this comment.
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 <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
4bd75e7 to
5ce7e0a
Compare
… limit Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Signed-off-by: Teju Nareddy <nareddyt@google.com>
|
What does [DNS] refer to in the PR title? |
Signed-off-by: Teju Nareddy <nareddyt@google.com>
alyssawilk
left a comment
There was a problem hiding this comment.
@snowp or @mattklein123 would one of you be up for final pass?
|
I can take a look. |
mattklein123
left a comment
There was a problem hiding this comment.
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 <nareddyt@google.com>
|
CI will fail until #15075 is merged. |
|
/retest |
|
Retrying Azure Pipelines: |
Signed-off-by: Teju Nareddy <nareddyt@google.com>
mattklein123
left a comment
There was a problem hiding this comment.
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 <nareddyt@google.com>
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 413orHTTP 500instead.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.
trueby default:envoy.reloadable_features.grpc_json_transcoder_adhere_to_buffer_limitsTesting:
Docs Changes: None
Release Notes: Yes
Platform Specific Features: None