http: proxying 104s Upload Resumption Supported

[Nealsoni00]

Proxying 104s from upstream.

104 Upload Resumption Supported is introduced in draft-ietf-httpbis-resumable-upload spec.

Continuation of the discussion in #19044
Modeled after: #19023

Risk Level: Low (minor refactor)
Testing: new integration test
Docs Changes: N/A

Release Notes:

http: envoy will now proxy 104 headers from upstream, though as with 100s only the first 1xx response headers will be sent. This behavior can be temporarily reverted by setting runtime guard envoy.reloadable_features.proxy_104 to false. 104 headers are designated by ietf's draft-ietf-httpbis-resumable-upload rfc.

Runtime guard:

envoy.reloadable_features.proxy_104

[repokitteh-read-only]

Hi @Nealsoni00, welcome and thank you for your contribution.

We will try to review your Pull Request as quickly as possible.

In the meantime, please take a look at the contribution guidelines if you have not done so already.

🐱

Caused by: #34738 was opened by Nealsoni00.

see: more, trace.

[RyanTheOptimist]

Looks like this fails to build

# Execution platform: @local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
source/common/http/header_utility.cc:239:57: error: expected ')'
          (response_headers.Status()->value() == "104") {
                                                        ^
source/common/http/header_utility.cc:238:6: note: to match this '('
  if (Runtime::runtimeFeatureEnabled("envoy.reloadable_features.proxy_104") &&
     ^
1 error generated.
INFO: Elapsed time: 51.685s, Critical Path: 17.41s
INFO: 34267 processes: 20413 remote cache hit, 13851 internal, 1 local, 2 processwrapper-sandbox.
//test/common/common:base64_fuzz_test                           FAILED TO BUILD

Please update the release notes.

/wait

[Nealsoni00]

@RyanTheOptimist Build fix incoming.

Where should I add release notes (other than in the PR description)?

http: envoy will now proxy 104 headers from upstream, though as with 100s only the first 1xx response headers will be sent. his behavioral can be temporarily reverted by setting runtime guard envoy.reloadable_features.proxy_104 to false. 104 headers are designated by ietf's draft-ietf-httpbis-resumable-upload rfc.

[Nealsoni00]

@RyanTheOptimist Is the change I made sufficient to test the propagation of the Upload-Draft-Interop-Version header?

[RyanTheOptimist]

/wait
Looks like it needs a main merge?

[Nealsoni00]

@RyanTheOptimist not sure why tests are failing — verified those same tests are failing on master.

[RyanTheOptimist]

/wait
Try doing a main merge and see if that resolves the issues?

[Nealsoni00]

@RyanTheOptimist It should be good now!

[Nealsoni00]

@RyanTheOptimist sorry to re-ping. Would love to get this into master before it becomes out of date!

Once in, what's the process to deprecate the runtime flag? Should I create a PR to remove it and leave it to y'alls discretion to merge when appropriate?

[alyssawilk]

I've sent you an invite to the "assignable" group - in ~6m when we cut the release where this is no longer needed the tool will file an issue your way that removal is appropriate.

[Nealsoni00]

@alyssawilk happy to help clean up the runtime flag here — is there a ticket i should associate it to?

[alyssawilk]

again an issue will get auto-filed ~6m from the original PR