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.

Sign up for GitHub

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

Jump to bottom

quiche: add 100 continue support #14246

Merged

alyssawilk merged 5 commits into envoyproxy:main from danzh2010:100continue

Jan 27, 2021

Contributor

danzh2010 commented Dec 2, 2020 •

edited

Loading

Signed-off-by: Dan Zhang [email protected]

Commit Message: Add 100 continue support to envoy_quic_client_stream. Fix some quic stream and stream decoder interaction issues.
Additional Description: issues fixed:
Following StreamDecoder callbacks shouldn't be called if decodeHeaders|Data|Traiers() causes stream is reset or connection close.
decodeHeaders|Data|Traiers() shouldn't be called if quic header/trailers are too large.
StreamCallback::onResetStream() shouldn't be called if end_stream is decoded.

Risk Level: low, not in use
Testing: Added more stream unit tests and an e2e test

Part of #2557

danzh1989 added 2 commits

December 1, 2020 15:17


          add 100 continue

00c5734

Signed-off-by: Dan Zhang <[email protected]>


          add tests

5bafa4a

Signed-off-by: Dan Zhang <[email protected]>

danzh2010 requested review from alyssawilk, ggreenway and mattklein123 as code owners

December 2, 2020 18:48

Contributor Author

danzh2010 commented Dec 2, 2020

/assign @alyssawilk

repokitteh-read-only bot assigned alyssawilk

alyssawilk reviewed

View reviewed changes

Contributor

alyssawilk left a comment

Awesome - so exciting to see the corner cases in QUIC getting handled!

source/extensions/quic_listeners/quiche/envoy_quic_client_stream.cc Show resolved Hide resolved

source/extensions/quic_listeners/quiche/envoy_quic_client_stream.cc Outdated

-                response_decoder_->decodeHeaders(
-                    quicHeadersToEnvoyHeaders<Http::ResponseHeaderMapImpl>(header_list),
-                    /*end_stream=*/fin);
+                ENVOY_STREAM_LOG(debug, "Receive headers: {}.", *this, header_list.DebugString());

Contributor

alyssawilk Dec 3, 2020

Receive -> Received, here and below

Contributor Author

danzh2010 Dec 3, 2020

done

source/extensions/quic_listeners/quiche/envoy_quic_client_stream.cc Outdated

+                const uint64_t status = Http::Utility::getResponseStatus(*headers);
+                if (status >= 100 && status < 200) {
+                  // These are Informational 1xx headers, not the actual response headers.
+                  ENVOY_STREAM_LOG(debug, "Received informational response code: {}", *this, status);

Contributor

alyssawilk Dec 3, 2020

is this redundant given full headers logged above?

Contributor Author

danzh2010 Dec 3, 2020

removed

source/extensions/quic_listeners/quiche/envoy_quic_client_stream.cc Outdated

+                std::unique_ptr<Http::ResponseHeaderMapImpl> headers =
+                    quicHeadersToEnvoyHeaders<Http::ResponseHeaderMapImpl>(header_list);
+                const uint64_t status = Http::Utility::getResponseStatus(*headers);
+                if (status >= 100 && status < 200) {

Contributor

alyssawilk Dec 3, 2020

CodeUtility::is1xx ?

Contributor Author

danzh2010 Dec 3, 2020

done

source/extensions/quic_listeners/quiche/envoy_quic_client_stream.h Show resolved Hide resolved


          debug logging

85465ff

Signed-off-by: Dan Zhang <[email protected]>

alyssawilk reviewed

View reviewed changes

source/extensions/quic_listeners/quiche/envoy_quic_client_stream.cc

+                std::unique_ptr<Http::ResponseHeaderMapImpl> headers =
+                    quicHeadersToEnvoyHeaders<Http::ResponseHeaderMapImpl>(header_list);
+                const uint64_t status = Http::Utility::getResponseStatus(*headers);
+                if (Http::CodeUtility::is1xx(status)) {

Contributor

alyssawilk Dec 7, 2020

So what happens with 1xx headers which are not 100-continue?

For non-QUIC we send them up via decodeHeaders.

Contributor Author

danzh2010 Dec 10, 2020 •

edited

Loading

Oh, I didn't know that. Currently we drop these headers on the floor. Will fix it.
Question please: QUIC doens't support 101 response code: https://tools.ietf.org/html/draft-ietf-quic-http-32#section-4.3. What shall we do in that case?

Contributor

alyssawilk Dec 10, 2020

oh fair point. maybe treat it as invalid and fast-fail the response then?

Contributor Author

danzh2010 Jan 25, 2021

Re-wrote 1xx header handling logic here. PTAL!

alyssawilk added the waiting label

github-actions bot commented Jan 14, 2021

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

github-actions bot added the stale label

Base automatically changed from master to main

January 15, 2021 23:02

github-actions bot commented Jan 23, 2021

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

github-actions bot closed this


          pass non-100 headers

48597cd

Signed-off-by: Dan Zhang <[email protected]>

Contributor Author

danzh2010 commented Jan 25, 2021

Can someone reopen this PR?

ggreenway reopened this

repokitteh-read-only bot removed the waiting label

danzh2010 mentioned this pull request

quiche: prevent nested buffer watermark accounting #14259

Merged

github-actions bot removed the stale label

Contributor Author

danzh2010 commented Jan 26, 2021

/retest

repokitteh-read-only bot commented Jan 26, 2021

Retrying Azure Pipelines:
Check envoy-presubmit didn't fail.
Check envoy-presubmit didn't fail.

🐱

Caused by: a #14246 (comment) was created by @danzh2010.

see: more, trace.

alyssawilk reviewed

View reviewed changes

Contributor

alyssawilk left a comment

LGTM modulo one test/TODO

test/extensions/quic_listeners/quiche/integration/quic_http_integration_test.cc

                              /*response_trailers_present=*/true);
               }
+              // Multiple 1xx before the request completes.
+              TEST_P(QuicHttpIntegrationTest, EnvoyProxyingEarlyMultiple1xx) {

Contributor

alyssawilk Jan 26, 2021

Think it's worth a test of the reset for 101 here, or want to TODO it for later?

Contributor Author

danzh2010 Jan 26, 2021

It is already unit tested and will be covered by protocol integration test once HTTP3 is added into the test.

Contributor Author

danzh2010 Jan 26, 2021

Sorry, I misunderstood the test for non-100 case. 101 response status is indeed a HTTP3 specific case. Added an integration test here.

alyssawilk previously approved these changes

View reviewed changes

Contributor

alyssawilk left a comment

Works for me :-)


          added e2e test for 101 response code

b7c9a2d

Signed-off-by: Dan Zhang <[email protected]>

danzh2010 dismissed alyssawilk’s stale review via

b7c9a2d

January 26, 2021 20:23

Contributor Author

danzh2010 commented Jan 26, 2021

Works for me :-)

Sorry for reverting my previous response, I added an e2e test intead. Mind taking another look?

alyssawilk approved these changes

View reviewed changes

Contributor

alyssawilk left a comment

Even better, thanks!

Contributor Author

danzh2010 commented Jan 27, 2021

Can this PR be merged now?

alyssawilk merged commit 53124e8 into envoyproxy:main

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet