v1.2 Release Scoping: New Experimental Features

[robscott]

Scoping for GEPs moving to Experimental in Gateway API v1.2 has now closed. GEPs that are in scope have been added to the v1.2 milestone.

The scoping has been done using the v1.2 Experimental discussion and the numbers have been run in the Scoping spreadsheet, so you can see how everything worked out.

For GEPs in scope:

• They must have a GEP PR merged at Implementable by July 30, 2024. If they don’t make this deadline, they will be removed from the scope for the actual release.
• Review bandwidth is limited, so please try to get PRs opened earlier rather than later. Multiple rounds of smaller changes are preferred to one big change as well.

For GEPs out of scope:

• We are sorry we don’t have capacity to get to everything, but we encourage everyone who has proposals that are out of scope to resubmit them for v1.3 when the scoping window opens for that release sometime in October.
• It’s okay for GEP PRs at Provisional to continue development, but reviews for this by maintainers will be lower priority than in-scope GEPs.

Thanks also to everyone who has committed to moving GEPs forward from Experimental to Standard, you can see this list in the v1.2 Standard discussion. There may be other GEPS (particularly Policy Attachment) that move into scope here later, keep an eye out for that. We should also note that if we don’t have all of these move forward, we may have to cut some GEPs from the Experimental -> Standard scope as a result. Get those GEP PRs in!

The current timeline for the rest of the v1.2 release looks like this:

• Scoping closed - June 11, 2024 (we are here)
• Iteration phase - July 30, 2024
• Refinement - Around the end of August
• Review, RCs, then final release - around end of September

This would leave us able to open the scoping phase for v1.3 sometime in October, in time for Kubecon NA 2024.

One last thing: please remember that anyone can review Gateway API PRs, not just the maintainers and GEP reviewers. Community reviews are super helpful and very much appreciated.

---

In v1.2, we're working towards a more predictable release process, and we're currently in the first phase of that process - scoping. This discussion is intended to be a central place for proposed additions to the experimental channel in v1.2.

If you have an enhancement that you would like to see included in Gateway API v1.2, and you personally have time to lead the development of the feature, please add a comment below using the following template:

# Proposal Name Goes Here

**1. Describe the proposed feature**

**2. Why is this feature important for Gateway API?**

**3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)**

**4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?**

**5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)**

Ultimately, we'll likely have more proposals here than the project has room for. Each feature that leaves experimental channel in a release gives us an opening to add a feature to experimental channel, and we're expecting somewhere between 3 and 5 in this cycle. (You can help the project move more quickly and accept more new features by helping us move features out of experimental channel - see #3128 for details). Even if you don't have time to lead a feature, you can help us prioritize the features proposed in this thread by:

• Upvoting proposals that you would like to see move forward
• Adding a comment below a specific proposal to note that your implementation would work to support the feature
• Adding a comment below a specific proposal that you would be able to help lead a proposal to completion
• Adding a comment below a specific proposal to make a case for the inclusion of this proposal

The scoping process is scheduled to wrap up on June 11, 2024. Please have all proposals in place at least 1 week before that point so everyone has sufficient time to comment and vote on proposals.

It's worth noting that maintainers will still have some discretion in terms of which proposals are accepted into the scope of a release, but the information gathered here will be the primary consideration for which proposals are included in v1.2. Essentially we're hoping to prioritize features that:

1. Are broadly implementable
2. Have significant community support
3. Will encourage more adoption of the API
4. Introduce minimal cost to our "complexity budget"
5. Have strong leadership that will follow through with the proposal

[robscott]

Complete Backend mTLS Configuration

1. Describe the proposed feature
I'd like to bundle three related changes together as part of a broader effort to enable Backend mTLS configuration:

1. Configuration for the client certificate Gateways should use when connecting to Backends
2. Ability to specify SANs on BackendTLSPolicy
3. Add TLS options to BackendTLSPolicy to mirror TLS config on Gateways

Of those, 2 may not seem quite as obvious as the rest. The rationale is that SPIFFE is very commonly used as part of mTLS, and is not compatible with our current requirement that the cert served by the backend must match the SNI used to connect to the backend. Adding the option to separately specify SANs would also enable the use of SPIFFE IDs with BackendTLSPolicy.

2. Why is this feature important for Gateway API?
One of the core goals for Gateway API is to provide more secure capabilities than Ingress. This feature would finally allow backend mTLS to be configured natively within Kubernetes APIs, and would likely provide opportunities for closer integration between ingress-focused implementations of this API and mesh-focused implementations.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)
All of Envoy, HAProxy, and NGINX should be able to support these capabilities, but there will be some nuance in terms of where the configuration lives.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
Yes. I'm open to assistance though. I'd expect @candita will be involved as this will likely touch BackendTLSPolicy.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)
Previous GEP: #1897
Prior Art: https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/how-to-backend-mtls-gateway-api?tabs=alb-managed
Broader vision: https://gateway-api.sigs.k8s.io/geps/gep-2907/

[ReToCode]

Awesome, as @dprotaso pointed out in the other issues, we'd be very interested in seeing this (especially 2.) happening as we'd need this for Knative's encryption story (BackendTLSPolicy targeting two different SANs). @candita I'm happy to help on this as well.

[mikemorris]

@snehachhabria You may be interested in helping with this, as it could look similar to upstreaming into the Gateway API spec functionality already implemented by AGC.

[keithmattix]

Seems related to https://gateway-api.sigs.k8s.io/geps/gep-2907/?

[robscott]

Good call @keithmattix, added link to my original comment as well.

[robscott]

This proposal has made the cut for v1.2 scoping. That means that we have 7 weeks (July 30) to get this GEP merged as “implementable”. Given the limited review bandwidth, please aim to have your proposal ready for review before the end of June. The earlier your proposal is ready for review, the greater the likelihood that this will make it into v1.2. There are a lot of GEPs in scope for v1.2, and not a lot of reviewers, please don’t underestimate how long review will take. If this GEP is not fully approved and marked as implementable by July 30, it will be dropped from the scope of the v1.2 release.

[guicassolato]

Named Route rules

1. Describe the proposed feature
Addition of an optional field name to the rules of HTTPRoutes, GRPCRoutes, and other route types.

2. Why is this feature important for Gateway API?
It will allow implementations to support referencing individual rules by name, including (though not limited to):

• from other resources (e.g. policies);
• in status condition messages;
• by observability and networking tools.

The lack of this field makes referencing route rules overly complex, less assertive and prone to errors. Less effective alternatives include: relying on the index position of element in the list of rules, as well as non-standardized and protocol-specific patterns for generating unique identifiers out of route rule definitions.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)
All of Envoy could support it OOTB. Possibly HAProxy as well (via ACLs). As for NGINX, I'm not aware of existence of a direct mapping between named route rules at the API level and the proxy's internal configs. Other implementations TBC.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
Yes, though the heavy work at the API side has been done already by @howardjohn at #2985.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

• GEP-995
• Implement of GEP-995 #2985

[arkodg]

+1

[robscott]

Congrats! This proposal has made the cut for v1.2 scoping. That means that we have 7 weeks (July 30) to get this GEP merged as “implementable”. Given the limited review bandwidth, please aim to have your proposal ready for review before the end of June. The earlier your proposal is ready for review, the greater the likelihood that this will make it into v1.2. There are a lot of GEPs in scope for v1.2, and not a lot of reviewers, please don’t underestimate how long review will take. If this GEP is not fully approved and marked as implementable by July 30, it will be dropped from the scope of the v1.2 release.

[lianglli]

Query Parameter Filter

1. Describe the proposed feature
Provide a way to modify query parameters of an incoming request in a HTTPRoute.

2. Why is this feature important for Gateway API?
Just like modify header is useful, the same goes for query parameters.
It's helpful to have a HTTPQueryParamFilter field in HTTPRouteFilter to set,
add and remove a query parameter of the HTTP request before it is sent to the upstream target.

The query parameters are an important part of the request URL.
The developers can use query parameters to filter, sort or customize data of request body.
Backend service can enable different function based on the query parameters.
Query parameters are important information about search and track.
Moreover, query parameter, headers and cookies are common techniques used in a canary release.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

• NGINX supports it using the set directive.
• Envoy has a feature request Support adding/removing query params and PR #33977 about query parameters filter.
• Traefik supports this with a Query Parameter Modification plugin.
• KONG supports adding/removing query params with a Request Transformer plugin.
• Tengine-Ingress supports this with annotation nginx.ingress.kubernetes.io/canary-request-add-query.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
Yes.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

• issue GEP: Add support for query parameter in the HTTPRouteFilter API
• PR GEP-2895: Query Parameter Filter
• relevant issue:
  gateway-api: support VirtualService-kind routes on k8s gateways

[arkodg]

+1

[robscott]

Unfortunately we do not have sufficient capacity to include this proposal in the v1.2 scope. Ultimately we have a limited capacity for new features in each release, and although this is a great proposal, it just didn’t meet the bar this time. Many of the proposals that have made it into the scope for this release have already been in the works for some time, so this is not a “no”, just a “not yet”. In the meantime, it’s fine to iterate on a provisional GEP for this, but this will not be able to move to implementable in this release cycle, and review bandwidth for these provisional GEPs will be quite limited. Please consider resubmitting this in the future for v1.3. The v1.3 scoping process is likely to begin in October 2024.

[lianglli]

HTTP Cookie Match

1. Describe the proposed feature

1. Support cookie matching in a HTTPRoute
2. Add a new match type List

2. Why is this feature important for Gateway API?
Cookie is an essential part of the HTTP request. The Cookie header has multiple cookie-pair which contains the cookie-name and cookie-value. Just like HTTP route based on header and query parameter is common, it’d be helpful to have a HTTPCookieMatch field in HTTPRouteMatch which would let gateway forwards request based on cookie to the certain backends.

Cookies are used to maintain state and identify specific users. Moreover, cookies, headers and query parameters are common techniques used in a canary release.
Currently HTTPRouteMatch API supports the following condition: path, method, header and query parameter. This GEP proposes adding support for cookie matching in a HTTPRoute.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

• NGINX supports it using the cookie_name variable.
• Envoy has PR #21496 and #16344 about HTTP cookie matching.
• Ingress-nginx supports this with an annotation nginx.ingress.kubernetes.io/canary-by-cookie.
• NGINX Ingress Controller supports this with CRD Condition.
• Tengine-ingress supports this with annotations nginx.ingress.kubernetes.io/canary-by-cookie and nginx.ingress.kubernetes.io/canary-by-cookie-value.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
Yes.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)
issue

• issue GEP: Add support for cookie in the HTTPRouteMatch API
• PR GEP-2891: HTTP Cookie Match
• relevant issue:
  HTTPCookieMatching
  httproute add ipmatch and cookiematch
  bug: multiple header value matching semantics

[arkodg]

+1

[robscott]

Unfortunately we do not have sufficient capacity to include this proposal in the v1.2 scope. Ultimately we have a limited capacity for new features in each release, and although this is a great proposal, it just didn’t meet the bar this time. Many of the proposals that have made it into the scope for this release have already been in the works for some time, so this is not a “no”, just a “not yet”. In the meantime, it’s fine to iterate on a provisional GEP for this, but this will not be able to move to implementable in this release cycle, and review bandwidth for these provisional GEPs will be quite limited. Please consider resubmitting this in the future for v1.3. The v1.3 scoping process is likely to begin in October 2024.

[dprotaso]

Standard Mechanism to Merge Multiple Gateways

1. Describe the proposed feature

Support for merging Gateways should have standard & documented mechanic.

2. Why is this feature important for Gateway API?

Prior Discussions: #1248, #1246

Knative generates on demand per-service certificates using HTTP-01 challenges. There can be O(1000) Knative Services in the cluster which means we have O(1000) distinct certificates. The Gateway Resource is a contention point since is the only place to attach listeners to gateways with certificates.

The spec currently has language to indicate implemenations MAY merge Gateways resources but the mechanic isn't defined.

gateway-api/apis/v1beta1/gateway_types.go

Lines 76 to 78 in 541e9fc

	// determines that the Listeners in the group are "compatible". An
	// implementation MAY also group together and collapse compatible
	// Listeners belonging to different Gateways.

Secondly, given similar use-cases/needs for control planes to manage listeners it might make sense that merging Gateways is part of extended conformance.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

I believe Contour has prototyped this GEP. Envoy Gateway has a similar feature to merge gateways (https://gateway.envoyproxy.io/v0.6.0/api/extension_types/#envoyproxyspec)

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?

Yes

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

GEP is out and has some comments: #1863

[mikemorris]

It feels like we've finally removed almost all the prerequisite blockers to this and I'd like to see us figure how how to finalize this mechanism.

[kflynn]

This is a practical necessity, I think.

[robscott]

Congrats! This proposal has made the cut for v1.2 scoping. That means that we have 7 weeks (July 30) to get this GEP merged as “implementable”. Given the limited review bandwidth, please aim to have your proposal ready for review before the end of June. The earlier your proposal is ready for review, the greater the likelihood that this will make it into v1.2. There are a lot of GEPs in scope for v1.2, and not a lot of reviewers, please don’t underestimate how long review will take. If this GEP is not fully approved and marked as implementable by July 30, it will be dropped from the scope of the v1.2 release.

[mikemorris]

Configurable Retries in HTTPRoute

1. Describe the proposed feature

It should be possible to configure when and how requests on a given HTTPRoute are retried:

• The mechanism for determining whether and how many times a request should be retried, which should be Extended functionality and support two approaches:
  • Max count retries
  • Budgeted retries
• The reason(s) and/or status code(s) for which a request from a Gateway to a backend should be considered for retrying
• The timeout for each retry attempt and relationship to GEP-1742: HTTPRoute Timeouts
  • https://stackoverflow.com/questions/68224451/how-timeout-and-retries-works-together-in-istio
  • https://linkerd.io/2.15/features/retries-and-timeouts/

It may also be worth exploring whether retry semantics should be configurable as a Service-targeted policy instead of or in addition to HTTPRoute, such as suggested in https://gateway-api.sigs.k8s.io/geps/gep-713/#targeting-virtual-types

2. Why is this feature important for Gateway API?

Configuring retries is a core capability for ensuring service networking resiliency, and has been requested by multiple implementations. Specifically, this is a core gap for both Istio (as the current configuration requires an EnvoyFilter extension) and for Linkerd to recommend further adoption of HTTPRoute over their ServiceProfile resource, as well as being common functionality for N/S ingress implementations.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

For max count retries, all three requirements should be implementable for Envoy based implementations, the first two would be implementable for HAProxy based implementations, and it's currently unclear what would be implementable for NGINX or others - the first step here would be a provisional GEP documenting existing capabilities of prospective implementations.

Linkerd only supports budgeted retries. Envoy does have an implementation of retry budgets as a "circuit breaker" and configuring budgeted retries has been requested functionality from Istio users, but may require some upstream work in Envoy to implement this for incoming requests instead of outgoing.

• Expose retry budget configuration istio/istio#27419
• gateway-api: add timeouts and retries support istio/istio#44571
• Support Retry Budget istio/api#2734
• Extend DestinationRule with retry budget istio/api#2585

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?

Yes

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

#1731
#184

[dprotaso]

Knative needs a way to disable retries for HTTP semantic errors. We generally want to retry if it's a connection error.

[kflynn]

Yeah, let's do this. Retries are table stakes.

[robscott]

Congrats! This proposal has made the cut for v1.2 scoping. That means that we have 7 weeks (July 30) to get this GEP merged as “implementable”. Given the limited review bandwidth, please aim to have your proposal ready for review before the end of June. The earlier your proposal is ready for review, the greater the likelihood that this will make it into v1.2. There are a lot of GEPs in scope for v1.2, and not a lot of reviewers, please don’t underestimate how long review will take. If this GEP is not fully approved and marked as implementable by July 30, it will be dropped from the scope of the v1.2 release.

[mikemorris]

Static Infrastructure Attachment

1. Describe the proposed feature

Add the capability for a Gateway resource to program infrastructure that has been provisioned by some other means (e.g. via Helm), but for which the implementation may or may not actually manage the lifecycle of that underlying infrastructure.

2. Why is this feature important for Gateway API?

This deployment model is currently a requirement for some implementations and an optional deployment mode for others. Such a mode can be particularly helpful for allowing legacy/pre-operator deployments to have Gateway API functionality. We should incorporate this into the Gateway API spec to ensure it's possible to configure this in a standardized way and enable implementations for which this is a requirement to pass the conformance suite.

This feature would be complementary to (but not dependent on) the "gateway merging" standardization happening in #1863.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

This deployment model is currently required by:

• NGINX
• Azure Application Gateway for Containers

Additionally, it is optional for:

• Contour
• Istio
• Kong
• Linkerd

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?

Yes. I'm hoping @snehachhabria and @kate-osborn may be able to assist with advancing this.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

#1687
#2945
5cd70cb
#892
#925

[kflynn]

The fact that Gateway API expects to provision the infrastructure trips pretty up a lot of people at the moment, so I'm in favor of making it optional.

[robscott]

Unfortunately we do not have sufficient capacity to include this proposal in the v1.2 scope. Ultimately we have a limited capacity for new features in each release, and although this is a great proposal, it just didn’t meet the bar this time. Many of the proposals that have made it into the scope for this release have already been in the works for some time, so this is not a “no”, just a “not yet”. In the meantime, it’s fine to iterate on a provisional GEP for this, but this will not be able to move to implementable in this release cycle, and review bandwidth for these provisional GEPs will be quite limited. Please consider resubmitting this in the future for v1.3. The v1.3 scoping process is likely to begin in October 2024.

[jakebennert]

Percentage-Based Request Mirroring

1. Describe the proposed feature
Request Mirroring is a feature that allows a user to mirror requests going to some backend A along to some other specified backend B. Right now Request Mirroring is an all or nothing feature. Either 100% of request are mirrored, or 0% are. Percentage-Based Request Mirroring will allow users to specify a percentage of requests they'd like mirrored as opposed to every single request.

2. Why is this feature important for Gateway API?
This feature is already supported by Envoy, so adding it for the Gateway API would enable better integration between the two products. There's also an existing user desire for this feature on the HAProxy side and NGINX side. Since Request Mirroring is already supported by the Gateway API, Percentage-Based Request Mirroring would a clear improvement on this pre-existing feature.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)
This feature is already supported by Envoy, and should be supportable by HAProxy and NGINX.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
I have sufficient time and resources to lead the development of this feature.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)
There haven't been any discussions on this topic, but this is a small change, and a clear improvement on the current feature.

[robscott]

Congrats! This proposal has made the cut for v1.2 scoping. That means that we have 7 weeks (July 30) to get this GEP merged as “implementable”. Given the limited review bandwidth, please aim to have your proposal ready for review before the end of June. The earlier your proposal is ready for review, the greater the likelihood that this will make it into v1.2. There are a lot of GEPs in scope for v1.2, and not a lot of reviewers, please don’t underestimate how long review will take. If this GEP is not fully approved and marked as implementable by July 30, it will be dropped from the scope of the v1.2 release.

[arkodg]

Support Request Timeouts for GRPCRoute

1. Describe the proposed feature

A request.Timeout field within GRPCRoute similar to the one added in HTTPRoute as part of https://gateway-api.sigs.k8s.io/geps/gep-1742/

2. Why is this feature important for Gateway API?

• Set a request timeout for unary rpc, that may vary from the default timeout of the implementation
• Disable timeouts (set to 0s) for streaming rpc

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

Should be supportable on implementations that support GRPCRoute which do include implementations that use Envoy and NGINX as their underlying data plane

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?

Yes

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

#3139

[kflynn]

This feels mostly like a no-brainer; the xRoutes should be parallel except where there are very good reasons for them not to be.

[gnossen]

I'd just like to ensure that we define semantics for gRPC timeouts that make sense. Because of streaming RPCs and in particular, bidirectional streaming RPCs, some timeout implementations that work well for REST do not work well for gRPC. I think the semantics should be "timeout from when the first request message is started."

To give an example of a common data plane implementation that might get this wrong, within xDS, the timeout field corresponds to "timeout from when the request is finished." For unary RPCs, this might be okay, but for bidi, the timer is never actually started and no timeout is enforced at all. Instead within xDS, the appropriate field to use is max_stream_duration.grpc_timeout_header_max, which has the "timeout from when the first request message is started" semantics I mentioned above. Further context.

[robscott]

Congrats! This proposal has made the cut for v1.2 scoping. That means that we have 7 weeks (July 30) to get this GEP merged as “implementable”. Given the limited review bandwidth, please aim to have your proposal ready for review before the end of June. The earlier your proposal is ready for review, the greater the likelihood that this will make it into v1.2. There are a lot of GEPs in scope for v1.2, and not a lot of reviewers, please don’t underestimate how long review will take. If this GEP is not fully approved and marked as implementable by July 30, it will be dropped from the scope of the v1.2 release.

[lianglli]

CORS Filter

1. Describe the proposed feature
Provide a way to configure CORS in a HTTPRoute.

2. Why is this feature important for Gateway API?
The RFC 6454 defines the concept of an "origin". W3C recommend REC-cors-20140116. Then, RFC 7480 describes the registration data access protocol (RDAP) specifically.

Cross-Origin Resource Sharing (CORS) is supported by all browsers. Complex applications often reference third-party APIs and resources in their client-side code. CORS allows browsers to enforce the same-origin security policy for preventing client-side from accessing sensitive resources of a server on a domain different than the domain that served the web page.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

• NGINX supports it using the add_header directive.
• Envoy has a CORS filter envoy.filters.http.cors.
• Traefik supports this with the customResponseHeaders.
• KONG supports adding cross-origin resource sharing (CORS) to a service or a route with a CORS plugin.
• HAProxy can enable CORS functionality by using the HAProxy CORS Lua Library.
• ingress-nginx supports this with CORS annotation.
• NGINX Ingress Controller supports this with CRD ResponseHeaders.
• Tengine-Ingress supports this with CORS annotations.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
Yes.

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

• issue GEP: Add support for CORS
• issue Support the necessary functions of load balancing to gateway and route
• issue Can HTTPRoute support global filters

[robscott]

Unfortunately we do not have sufficient capacity to include this proposal in the v1.2 scope. Ultimately we have a limited capacity for new features in each release, and although this is a great proposal, it just didn’t meet the bar this time. Many of the proposals that have made it into the scope for this release have already been in the works for some time, so this is not a “no”, just a “not yet”. In the meantime, it’s fine to iterate on a provisional GEP for this, but this will not be able to move to implementable in this release cycle, and review bandwidth for these provisional GEPs will be quite limited. Please consider resubmitting this in the future for v1.3. The v1.3 scoping process is likely to begin in October 2024.

[dprotaso]

HTTPRoute-level SSL redirection

1. Describe the proposed feature

There's no simple way to enforce SSL redirection solely the route level.

A solution here could be being able to match on the scheme in the HTTPRoute. I'm open to others.

2. Why is this feature important for Gateway API?

This would help with redirect loops and http => http redirects.

Currently it requires two HTTPRoutes and configuring a two Gateway listeners to accomplish this. But that approach only works well if you have the ability to configure your Gateway.

The goal here is to support this feature at the HTTPRoute level.

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)

nginx/K8s Ingress has an annotation

ingress.kubernetes.io/force-ssl-redirect: "true"

Contour supports the above annotations.

I think this behaviour is pretty common in many implementaitons.

4. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you?
Yes

5. Are there any relevant links for previous discussions about this topic in Gateway API? (It would be particularly helpful if you can provide links showing strong interest for this feature)

#2809
#2455
Redirect Loop #1185 (comment)

[robscott]

Unfortunately we do not have sufficient capacity to include this proposal in the v1.2 scope. Ultimately we have a limited capacity for new features in each release, and although this is a great proposal, it just didn’t meet the bar this time. Many of the proposals that have made it into the scope for this release have already been in the works for some time, so this is not a “no”, just a “not yet”. In the meantime, it’s fine to iterate on a provisional GEP for this, but this will not be able to move to implementable in this release cycle, and review bandwidth for these provisional GEPs will be quite limited. Please consider resubmitting this in the future for v1.3. The v1.3 scoping process is likely to begin in October 2024.