-
Notifications
You must be signed in to change notification settings - Fork 5.1k
router: fix http/2 shadow request with body. #5674
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
Conversation
We need to buffer the decoded data before performing on complete processing. Fixes #5646 Signed-off-by: Matt Klein <mklein@lyft.com>
cc @irelandKen |
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.
Nice catch! I'm a bit unsure of the fix, so more questions than comments from me...
// buffer limit we give up on retries and buffering. We must buffer using addDecodedData() | ||
// so that all buffered data is available by the time we do request complete processing and | ||
// potentially shadow. | ||
callbacks_->addDecodedData(data, true); |
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 think this is the second time in as many weeks I've seen us have to do this workaround.
Not required for this PR but any thoughts for a change we could make to avoid this gotcha?
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.
Yeah this has come up a few times in slightly different contexts. I will think about this. I don't think there are any easy fixes here given the different permutations of things we need to support. The only thing I can think of quickly is to somehow indicate that a filter is of a particular type, and then the HCM would "pre-buffer." With that said, even that wouldn't work for the router filter because we buffer sometimes and not others...
Signed-off-by: Matt Klein <mklein@lyft.com>
@alyssawilk updated |
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.
Awesome, thanks for the fix and for the clarification!
FakeStreamPtr upstream_request2; | ||
ASSERT_TRUE(fake_upstreams_[0]->waitForHttpConnection(*dispatcher_, fake_upstream_connection2)); | ||
ASSERT_TRUE(fake_upstream_connection2->waitForNewStream(*dispatcher_, upstream_request2)); | ||
ASSERT_TRUE(upstream_request2->waitForEndStream(*dispatcher_)); |
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.
Boo, one of our utilities should work for this and they totally don't.
Goes on my TODO list :-)
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.
Yeah sorry I thought the same thing and was going to make the utility functions work for this, but I got lazy. I will circle back if you don't get to it first.
We need to buffer the decoded data before performing on complete processing. Fixes envoyproxy#5646 Signed-off-by: Matt Klein <mklein@lyft.com> Signed-off-by: Dan Zhang <danzh@google.com>
We need to buffer the decoded data before performing on complete processing. Fixes envoyproxy#5646 Signed-off-by: Matt Klein <mklein@lyft.com> Signed-off-by: Matt Klein <mattklein123@gmail.com>
We need to buffer the decoded data before performing on complete processing. Fixes envoyproxy#5646 Signed-off-by: Matt Klein <mklein@lyft.com> Signed-off-by: Fred Douglas <fredlas@google.com>
We need to buffer the decoded data before performing on
complete processing.
Fixes #5646
Risk Level: Medium. Scary code to change but pretty confident in
the change and I added an integration test.
Testing: New integration test.
Docs Changes: N/A
Release Notes: N/A