http: configurable ignore of HTTP/1.1 upgrades (#37642)

[dcillera]

Backport from 1.34

Fixes
#36305
and I think this is also related to:
istio/istio#53239

Add configuration to ignore HTTP/1.1 Upgrade headers . See https://datatracker.ietf.org/doc/html/rfc7230#section-6.7:

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @wbpcode
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #40407 was opened by dcillera.

see: more, trace.

[dcillera]

Hey @agrawroh I understood #4090 has fixed the problem. Hasn't it?
However, I would need a solution/workaround in release/v1.32 and in this release the rules_cc library is not present (I guess more commits would be needed to install and use it). Do you think we could re-open and merge this PR oly for 1.32? or your fix in #4090 is recommended?

[agrawroh]

Hey @agrawroh I understood #4090 has fixed the problem. Hasn't it? However, I would need a solution/workaround in release/v1.32 and in this release the rules_cc library is not present (I guess more commits would be needed to install and use it). Do you think we could re-open and merge this PR oly for 1.32? or your fix in #4090 is recommended?

@dcillera This was unintentional. The dependency PR had an incorrect link and when it got merged, GitHub closed this PR instead of the actual issue we wanted it to close.

[dcillera]

Thanks for re-opening it, @agrawroh :-)

[phlax]

/retest

[phlax]

@dcillera if we are backporting this to 1.32 - can we also add any other branches that require it please - at least 1.33

also a little apprehensive in that we dont generally backport features - is this arguably a bug fix ?

[dcillera]

@phlax This PR was intended to fix #36305 in 1.32.
But I have the following doubt . As the modification is concerned with API, I suppose that the corresponding modification in Istio is necessary and in fact there is:
istio/istio#53239
that is still open, even in newer releases.
What I would conclude is that the fix is not really available in any releases.

[phlax]

i see so iiuc arguably a fix but an imperfect one?

[dcillera]

I'll ask for more info to fully understand, because actually it was merged in: #37642

[wbpcode]

Hmmm, I basically OK to this backport. But for this a complex backport, I will inclinded let the maintainer to do that if it strongly is required for end users. Or we need take long time to review the code again and again. ESP this is merged for a while and I almost forget all previous impression.

[ggreenway]

Yes in general we don't backport features, but this one is to maintain compatibility with the ecosystem, so I'm ok with backporting it. But it must also go to 1.33; we can't support this in 1.32 and 1.34 but not 1.33.

[dcillera]

Hello @ggreenway, I also wonder if other modifications are necessary in Istio for the related configuration to be sent to Envoy through the API.

[phlax]

i will be cycling a set of patch release at latest tomorrow morning (european time) so if this is to be included it will need to land asap.

@dcillera can you raise for all other relevant branches please

@ggreenway gtm ?

[ggreenway]

@phlax that sounds fine as long as it's included in 1.33

[ggreenway]

I'll open backports PRs for both versions, as requested by @wbpcode