search

projectcontour / contour

Contour is a Kubernetes ingress controller using Envoy proxy.
https://projectcontour.io
Apache License 2.0
3.7k stars 672 forks source link

Add Per-HTTPProxy HTTP-Version Support to Address HTTP2 Coalescing Issues with Wildcards #5822

Open m-yosefpor opened 11 months ago

m-yosefpor commented 11 months ago

Description:

With the emergence of the HTTP2 Coalescing issue, where using a wildcard can result in complications in SNI-based routing (as fully discussed in multiple issues including https://github.com/projectcontour/contour/issues/1493), we've recognized a critical need to have a per-HTTPProxy mechanism to specify HTTP versions. This issue is exacerbated by browsers like Safari (or potentially underlining WebKit/CFNetwork) which does not retry upon receiving an HTTP 421 response. The proposed workaround for this issue is to universally disable http2 as mentioned in https://github.com/projectcontour/contour/issues/2619 and implemented in https://github.com/projectcontour/contour/pull/2622

We propose, adding a new field to the HTTPProxy spec allowing the specification of HTTP versions to offer for that HTTPProxy. This field comes into play only when spec.tls is activated and spec.tcpproxy is deactivated.

Critical Use Case:

In scenarios where multiple HTTPProxies are served, and a subset of them use the same wildcard certificate, it becomes imperative to have the flexibility to disable http/2 for specific proxies to avoid the mentioned issue. Meanwhile, we want to retain the performance advantages of http/2 for others, and also to be able to use gRPC routing for routes.

Proposed Solution:

  1. Selectively disable http/2 for HTTPProxies using the wildcard certificate, thus bypassing the 421 issue for problematic browsers.
  2. Retain the http/2 functionality for other routes to capitalize on grpc and enhanced performance.

Request:

Providing users the granularity to specify HTTP versions on a per-proxy basis, addressing the HTTP2 Coalescing challenge while balancing performance considerations. Furthermore, to ensure backward compatibility, if the new field in the HTTPProxy spec is not explicitly set, the behavior would default to using default-http-versions from the global configuration, provided it's not empty.

sunjayBhatia commented 7 months ago

Apologies, we got a bit behind reviewing the PR for this issue, bumping to 1.29.0