Skip to content

Comments

http: switching from 100 to 1xx#18904

Merged
alyssawilk merged 4 commits intoenvoyproxy:mainfrom
alyssawilk:1xx
Nov 10, 2021
Merged

http: switching from 100 to 1xx#18904
alyssawilk merged 4 commits intoenvoyproxy:mainfrom
alyssawilk:1xx

Conversation

@alyssawilk
Copy link
Contributor

Changing envoy APIs to reflect upcoming 102 support. This should be a functional no-op other than making every filter change their API calls :-/

Risk Level: Medium
Testing: n/a
Docs Changes: n/a
Release Notes: n/a
Part of #18844

@alyssawilk
Copy link
Contributor Author

Two notes. First I hate HeaderUtility::isSpecial1xx, but is1xxButNot101 seems awful too. Better ideas appreciated.
Second, I don't like making everyone implement encode1xx when they're not going to use it. If I'd had my way with encode100Continue being Continue in the base class, not everyone would have to change their APIs. What do we think of implementing 1xx in the base class so at least folks don't have to implement it this time around?

Signed-off-by: Alyssa Wilk <[email protected]>
Copy link
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, a few questions on how this all works

Comment on lines +1350 to +1351
if (HeaderUtility::isSpecial1xx(*headers)) {
pending_response_.value().decoder_->decode1xxHeaders(std::move(headers));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So any other 1xx header would currently just be handled as regular headers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah this is intentional for 101s but other codes get dropped in UpstreamRequest::decodeHeaders
honestly I think it'd be more clean to handle in the codecs, but then we'd be doing it in 3x places.

}

if (status == enumToInt(Http::Code::Continue) && !decoded_100_continue_) {
bool is_special_1xx = Http::HeaderUtility::isSpecial1xx(*headers);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const

Comment on lines +180 to +184
if (is_special_1xx && !decoded_1xx_) {
// This is 100 Continue, only decode it once to support Expect:100-Continue header.
decoded_100_continue_ = true;
response_decoder_->decode100ContinueHeaders(std::move(headers));
} else if (status != enumToInt(Http::Code::Continue)) {
decoded_1xx_ = true;
response_decoder_->decode1xxHeaders(std::move(headers));
} else if (!is_special_1xx) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my understanding: we allow multiple 100 on the decode path, but we just decode the first one and drop subsequent 100 headers? Is that something that actually happens?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, if we haven't decoded_1xx_ we pass it up, and otherwise we only encode if it's not a special 1xx.


// We drop 1xx other than 101 on the floor; 101 upgrade headers need to be passed to the client as
// part of the final response. 100-continue headers are handled in onUpstream100ContinueHeaders.
// We unsupported 1xx on the floor here. 101 upgrade headers need to be passed to the client as
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing drop

*
* This is not folded into encodeHeaders because most Envoy users and filters will not be proxying
* 100-continue and with it split out, can ignore the complexity of multiple encodeHeaders calls.
* 10s and with it split out, can ignore the complexity of multiple encodeHeaders calls.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

10s?


/**
* Called with 100-Continue headers to be encoded.
* Called with 1xx headers to be encoded.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the impl it seems we only pass a specific set of "special" 1xx headers here, should this be included in the comments?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I was trying to be lazy and not have to update all the comments in the next PR. I'll stop being lazy :-P

Signed-off-by: Alyssa Wilk <[email protected]>
Copy link
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/wait

public:
/**
* Encode supported 1xx headers.
* Currently only 1000-Continue headers are supported.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1000? :)

@yanavlasov yanavlasov self-assigned this Nov 9, 2021
Signed-off-by: Alyssa Wilk <[email protected]>
Copy link
Contributor

@snowp snowp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@alyssawilk alyssawilk merged commit d9c3927 into envoyproxy:main Nov 10, 2021
mpuncel added a commit to mpuncel/envoy that referenced this pull request Nov 10, 2021
* main: (71 commits)
  bazel: fix macOS build (envoyproxy#18920)
  http: switching from 100 to 1xx (envoyproxy#18904)
  grpc: implement BufferedAsyncClient for bidirectional gRPC stream (envoyproxy#18129)
  bazel: add repository arg to benchmark_test (envoyproxy#18795)
  rocketmq_proxy: Improvement for map find (envoyproxy#18909)
  tls: unit test: spiffe signed by intermediate cert (envoyproxy#18914)
  Test for FilterConfigPerRoute dtor called on worker thread. (envoyproxy#18927)
  deps: Bump `com_google_protobuf` -> 3.19.1 (envoyproxy#18930)
  deps: Bump `com_googlesource_code_re2` -> 2021-11-01 (envoyproxy#18933)
  cvescan: Move cvescan data to yaml (envoyproxy#18947)
  remove unnecessary file level not unimplemented hide annotation (envoyproxy#18924)
  test: moving echo test (envoyproxy#18938)
  test: fixing a test flake (envoyproxy#18899)
  deps: Revert pyparsing bump (envoyproxy#18946)
  deps: Bump `build_bazel_rules_apple` -> 0.32.0 (envoyproxy#18932)
  deps: Bump `com_github_bazelbuild_buildtools` -> 4.2.3 (envoyproxy#18931)
  build(deps): bump pycparser from 2.20 to 2.21 in /tools/dependency (envoyproxy#18936)
  quic: supporting connections with zero initial available streams (envoyproxy#18775)
  test: moving proxy proto (envoyproxy#18939)
  build(deps): bump pyparsing from 3.0.4 to 3.0.5 in /tools/dependency (envoyproxy#18937)
  ...

Signed-off-by: Michael Puncel <[email protected]>
dubious90 pushed a commit to envoyproxy/nighthawk that referenced this pull request Nov 15, 2021
- updates to `.bazelrc`
- rename of decode100ContinueHeaders to decode1xxHeaders according to envoyproxy/envoy#18904

Signed-off-by: tomjzzhang <[email protected]>
@alyssawilk alyssawilk deleted the 1xx branch August 4, 2022 01:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants