add per-httpproxy http-version support#5802
add per-httpproxy http-version support#5802therealak12 wants to merge 4 commits intoprojectcontour:mainfrom
Conversation
726105a to
ecd020f
Compare
ecd020f to
1f19118
Compare
Signed-off-by: Ahmad Karimi <ak12hastam@gmail.com>
1f19118 to
75ceb00
Compare
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
Just to make this active. |
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
/remove-lifecycle stale |
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
/remove-lifecycle stale |
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
/remove-lifecycle stale |
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
/remove-lifecycle stale |
skriss
left a comment
There was a problem hiding this comment.
Thanks @therealak12, and apologies for the delayed review here.
In addition to the inline comments:
- I'm not sure why codecov didn't run for the PR, but we'll need to ensure some test coverage for the new code paths. Either a combination of unit tests in
internal/dagandinternal/xdscache/v3, or a "feature test" ininternal/featuretests/v3should cover it. Let me know if you need more direction here. - It'd be good to update https://projectcontour.io/resources/faq/ (the question about Safari & 421's) to mention this
apis/projectcontour/v1/httpproxy.go
Outdated
|
|
||
| // HttpVersion is an alias to enforce validation | ||
| // +kubebuilder:validation:Enum=h2;http/1.1 | ||
| type HttpVersion string |
There was a problem hiding this comment.
Please use the following casing for the Go type/field:
| type HttpVersion string | |
| type HTTPVersion string |
| ) | ||
|
|
||
| // HttpVersion is an alias to enforce validation | ||
| // +kubebuilder:validation:Enum=h2;http/1.1 |
There was a problem hiding this comment.
Since we already have these constants defined in the ContourConfiguration struct (in v1alpha1) and the Contour config file, let's use the same values for them here for consistency:
| // +kubebuilder:validation:Enum=h2;http/1.1 | |
| // +kubebuilder:validation:Enum=HTTP/2;HTTP/1.1 |
Yes, this will then require a translation to the Envoy-accepted values, but we already have code for this in cmd/contour/parseDefaultHTTPVersions and internal/envoy/v3/ProtoNamesForVersions that we should be able to reuse, possibly with some refactoring required.
There was a problem hiding this comment.
The parseDefaultHTTPVersions converts from ["HTTP/1.1", "HTTP/2"] to HTTPVersionType.
The ProtoNamesForVersions function converts from HTTPVersionType to ["http/1.1", "h2"] .
Note that the desired format for Envoy configuration is ["http/1.1", "h2"]. So, why use the ["HTTP/1.1", "HTTP/2"] format at all instead of directly using ["http/1.1", "h2"]? 😅
Additionally, those functions cannot be easily imported since they're private, or importing them leads to import cycles unless we move them into a util-like package.
There was a problem hiding this comment.
This comment already answers my question. So thanks. I'll refactor.
apis/projectcontour/v1/httpproxy.go
Outdated
| // HttpVersions specify the http versions to offer for this HTTPProxy. | ||
| // If empty, the DefaultHTTPVersions from v1alpha1.EnvoyConfig will be used. | ||
| // It is ignored when TCPProxy is set. | ||
| HttpVersions []HttpVersion `json:"httpVersions,omitempty"` |
There was a problem hiding this comment.
I think this should move at least under the VirtualHost struct, since it is only applicable for root HTTPProxies that define a virtualhost. Still thinking about whether it should move under VirtualHost.TLS since it is really only relevant for TLS vhosts AFAIK. cc @sunjayBhatia and @tsaarni for any thoughts here.
There was a problem hiding this comment.
I think even if we should name it alpnProtos and not httpVersions? because it is only for the offered alpnProtos, so even if h2 is not offered in alpn proto, users can still use h2 with prior knowledge and it is still supported. also if permitInsecure is true, then h2c is supported as well. so maybe being more specific about it in the field name, helps people understand the actual behavior. WDYT? @therealak12 @skriss
There was a problem hiding this comment.
+1 for moving this under VirtualHost
internal/xdscache/v3/listener.go
Outdated
|
|
||
| alpnProtos = envoy_v3.ProtoNamesForVersions(cfg.DefaultHTTPVersions...) | ||
| if len(vh.HttpVersions) != 0 { | ||
| alpnProtos = vh.HttpVersions |
There was a problem hiding this comment.
In this case where the vhost specifies HTTP versions, I think we can also use the virtual host's HTTP versions for the HTTPConnectionManager's codec, above, since it's specific to the vhost.
There was a problem hiding this comment.
This comment still needs to be addressed
There was a problem hiding this comment.
Sure. I'll do when there's an agreement on this.
internal/dag/httpproxy_processor.go
Outdated
|
|
||
| // getSortedHttpVersions returns and empty slice or ["h2", "http/1.1"] or ["http/1.1"]. | ||
| // This is done to conform with how envoy expects AlpnProtocols in tlsv3.CommonTlsContext. | ||
| func (p *HTTPProxyProcessor) getSortedHttpVersions(proxy *contour_api_v1.HTTPProxy) []string { |
There was a problem hiding this comment.
It'd be nice to reduce the duplication between this new method, cmd/contour/parseDefaultHTTPVersions and internal/envoy/v3/ProtoNamesForVersions. I'll have to look some more for specific ideas on how to refactor for reuse but if you have ideas in the meantime they are welcome.
There was a problem hiding this comment.
Do agree to move parseDefaultHTTPVersions and ProtoNamesForVersions into a util package?
Signed-off-by: Ahmad Karimi <ak12hastam@gmail.com>
Signed-off-by: Ahmad Karimi <ak12hastam@gmail.com>
Signed-off-by: Ahmad Karimi <ak12hastam@gmail.com>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5802 +/- ##
==========================================
+ Coverage 78.61% 78.78% +0.17%
==========================================
Files 138 138
Lines 19231 19780 +549
==========================================
+ Hits 15118 15584 +466
- Misses 3824 3891 +67
- Partials 289 305 +16
|
| filters = envoy_v3.Filters(cm) | ||
|
|
||
| alpnProtos = envoy_v3.ProtoNamesForVersions(cfg.DefaultHTTPVersions...) | ||
| if len(vh.HTTPVersions) != 0 { |
There was a problem hiding this comment.
we need to make sure to have unit tests for this precedence behavior, i.e. when http versions are set in the virtualhost, they override the default
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
still needed |
|
Kindly ping @therealak12 Could you resolve what Sunjay mentioned. Thank you! |
Waiting for this: |
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |
|
The Contour project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to the #contour channel in the Kubernetes Slack |

This PR adds a new field to HTTPProxy spec which specifies the HTTP versions to offer for that HTTPProxy. It's used only when
spec.tlsis set andspec.tcpproxyis not.A critical use case for the field is when we're serving multiple HTTPProxies where a subset of them use the same wildcard certificate. We can disable http/2 for those utilizing this field while keeping it enabled for others.
Closes #5822