v1.4.0 Release-Cycle: Experimental Features

[shaneutt]

📣 The release cycle for Release v1.4.0 is starting. We anticipate releasing in time for Kubecon NA in November.

The purpose of this discussion is to do scoping for the Experimental features for this release.

Note: For Standard features for this release, see this discussion.

If you have something you want to submit for inclusion in this release, post here using the following template:

# Proposal Name Goes Here

1. Provide a link to the Issue for the proposed feature (required)

2. Describe the proposed feature

3. Why is this feature important for Gateway API?

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

5. Do you have sufficient time to lead the development of this feature
     in Gateway API? Do you have anyone else that can help you? (list all)

6. Do you have reviewers ready to support the progress of this feature? (list all)

7. 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)

When does scoping end?

As per the scoping documentation we are going to provide ~5 weeks for scoping. This means scoping concludes on Tuesday, May 20th, and at that time this thread will be locked and new features will not be accepted in scope past that point unless there are extenuating circumstances.

Upvoting

Comments on this thread can be upvoted by the community. The amount of upvotes a feature gets will help to inform the overall priority of features in this release. Please upvote as many issues as you like. Please leave an emoji 👍 as well, as this helps us know who voted for what.

Important Links

• Project Board
• Milestone
• Tracking Issue

Important Notes

WARNING: Posting in this thread is exclusively for submissions that meet the above criteria. For instance, this is not a place to suggest inclusion of a feature you're not ready to work on yourself: if you'd like to ask for volunteers for a feature you want, posting on the issue itself as well as using our Slack Channel and Community Meetings are the appropriate places. Off-topic posts will be deleted.

[shadialtarsha]

Gateway API Support for gRPC Retries

1. Provide a link to the Issue for the proposed feature (required)
   Retry Policy for GRPCRoute #3440

2. Describe the proposed feature
   Add support for gRPC retries to GRPCRoute.

3. Why is this feature important for Gateway API?
   Retries are a fundamental feature of keeping services reliable and resilient. Currently, HTTPRoute supports a retry API, and I am proposing to bring this to GRPCRoute as well.

4. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)
   Envoy, HAProxy, Linkerd, and Nginx all support retries for gRPC in some form. However, Envoy is the only proxy supporting retrying on gRPC status codes. The other proxies are retrying on timeouts, network errors, and HTTP status codes.

5. Do you have sufficient time to lead the development of this feature in Gateway API? Do you have anyone else that can help you? (list all)
   Yes, I do.

6. Do you have reviewers ready to support the progress of this feature? (list all)
   I don't think I do, but happy to reach out to folks here for help.

7. 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: GEP-3440 - Gateway API Support for gRPC Retries #3441

[lianglli]

Match multiple values for the same header/cookie/query

1. Provide a link to the Issue for the proposed feature (required)
   GEP: Match multiple values for the same header/cookie/query #3768

2. Describe the proposed feature
   A new match type List is added. Matches if the value of the header/query parameter/cookie with name field is present in a list of strings.

3. Why is this feature important for Gateway API?
   For a HTTP header/Cookie/Query, it can be have multiple values for the same key (i.e., the same header name, cookie name or query parameter name).

4. How broadly supportable would this feature be?
   (Look at Envoy, HAProxy, and NGINX as a baseline)
   Most implementations already support matching multiple values for the same header/cookie/query.

• Envoy has PR Multi-value header matching API #13751.
• Tengine supports HTTP routing based on multiple values of a specific header, cookie or query parameter.

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)
   Yes.

6. Do you have reviewers ready to support the progress of this feature? (list all)

7. 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)
   bug: multiple header value matching semantics #213

[shaneutt]

@lianglli we really appreciate your drive here! We would like to talk this over a bit though, we have a couple of questions:

• You created several submissions, which within itself is potentially OK, but I suspect realistically only 1 or 2 of these will actually move forward during this timeline. Is that also your perspective?
• Also I noticed you skipped question 6 for your entries. The skipping of some of our required questions plus how many things you're pushing for at one time makes me concerned that these submissions might be on thin structure. Would you be open to bringing these up at one of the upcoming community calls so we can try to find allies who would join you (for development and/or review), and generally try to talk through these a bit?

[shaneutt]

@lianglli we'll need a response soon about the above. If we don't receive one, note that we may decide to remove these submissions temporarily.

[lianglli]

HTTP Cookie Match

1. Provide a link to the Issue for the proposed feature (required)
   GEP: Add support for cookie in the HTTPRouteMatch API #2891
   

2. Describe the proposed feature
   Support cookie matching in a HTTPRoute

3. 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.

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

• NGINX supports it using the cookie_name variable.
• 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.

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)
   Yes

6. Do you have reviewers ready to support the progress of this feature? (list all)

7. 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)
   HTTPCookieMatching
   httproute add ipmatch and cookiematch

Originally posted by @lianglli in v1.2 #3103 (comment)
Originally posted by @lianglli in v1.3 #3403 (comment)

[lianglli]

Query Parameter Filter

1. Provide a link to the Issue for the proposed feature (required)
   GEP: Add support for query parameter in the HTTPRouteFilter API

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

3. 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.

4. 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.

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)
   Yes

6. Do you have reviewers ready to support the progress of this feature? (list all)

7. 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

Originally posted by @lianglli in v1.2 #3103 (comment)
Originally posted by @lianglli in v1.3 #3403 (comment)

[lianglli]

Support HTTP/3

1. Provide a link to the Issue for the proposed feature (required)
   GEP: Enable or disable HTTP/3 of a host

2. Describe the proposed feature
   A specific config for enable/disable HTTP/3 of a host.

3. Why is this feature important for Gateway API?

Most browsers have support HTTP/3. However, if the server (host) supports HTTP/3, it will return response header Alt-Svc with h3 protocol, listen port and fresh time specifically.

Based on ResponseHeaderModifier for enable HTTP/3 of a host, HTTPRoute owner need to get h3 protocol (E.g., h3 and h3-29) and h3 listening port of the gateway specifically.

Hence, It's better to have a HTTPRoute config for enable/disable HTTP/3 of a host.

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

• Envoy supports HTTP/3 downstream for production use.
• NGINX supports HTTP/3 since 1.25.0.
• Tengine supports HTTP/3 since 3.0.0.

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)
   Yes

6. Do you have reviewers ready to support the progress of this feature? (list all)

7. 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)
   HTTP3 and QUIC support #687

[youngnick]

I'd like to see further movement on this, but this also will need definition at the Listener and Protocol level. This is not a straightforward GEP, I anticipate it will need a lot of discussion.

[lianglli]

DirectResponse Filter

1. Provide a link to the Issue for the proposed feature (required)
   Support DirectResponse HTTPRouteFilter #2826

2. Describe the proposed feature
   Adding a catch-all / fallback route to HTTPRoute

3. Why is this feature important for Gateway API?

DirectResponse Filter can be used to send a fixed response to clients for some HTTPRoute.

For example, some hosts want to disable crawl any of the website's pages.
If the request path is "/robots.txt", the gateway will return 200 OK with body
"User-agent: *
Disallow: /".

For example, if there is a L7 attack, the directResponse will return 404 based on a new HTTPRoute asap.
Then, the upstream service will be able to process the normal requests without any changes.

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

• Envoy direct_response
• istio HTTPDirectResponse
• Contour HTTPDirectResponsePolicy
• NGINX directive return

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)
   Yes

6. Do you have reviewers ready to support the progress of this feature? (list all)
   arkodg

7. 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)
   Support DirectResponse HTTPRouteFilter #2826

[youngnick]

I'm okay with this, but as I've said before, I expect strict limits that we won't increase without good reason on the body size. 1024 characters seems acceptable for me. This is not for serving complete static sites using a Gateway implementation.

[arkodg]

Improve Client Certificate Verification for the Gateway

1. Provide a link to the Issue for the proposed feature (required)
   GEP: Client Certificate Verification for Gateway Listeners #91)

2. Describe the proposed feature

• Add a top level field for frontendValidation to avoid the auth bypass that may occur with HTTP/2 connection coalescing highlighted in https://gateway-api.sigs.k8s.io/geps/gep-3567/#interaction-with-client-cert-validation
• Add another field / modify existing fields to represent optional client certificate validation

3. Why is this feature important for Gateway API?
   Client Certificate Verification for external clients connecting to the Gateway is a common use case

4. How broadly supportable would this feature be?
   (Look at Envoy, HAProxy, and NGINX as a baseline)
   https://gateway-api.sigs.k8s.io/geps/gep-91/#existing-support-in-implementations

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)
   Yes, with help from @kl52752, tia !

6. Do you have reviewers ready to support the progress of this feature? (list all)
   @robscott @youngnick

7. 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)
   https://kubernetes.slack.com/archives/CR0H13KGA/p1743811567291379?thread_ts=1743673440.463289&cid=CR0H13KGA

[LiorLieberman]

Support East-West (E/W) Authorization

1. Provide a link to the Issue for the proposed feature (required): Support E/W authorization #3779

2. Describe the proposed feature:

Adding a new API to standardize basic, identity-based E/W authorization for mesh implementations.

3. Why is this feature important for Gateway API?

East/West (E/W) authorization is a critical part of any service mesh. To ensure GAMMA can be used as a standalone solution by a broad user base, it must include some form of E/W authorization.

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

   Most if not all mesh implementations support E/W authorization in their projects.

5. Do you have sufficient time to lead the development of this feature
   in Gateway API? Do you have anyone else that can help you? (list all)

   Yes

6. Do you have reviewers ready to support the progress of this feature? (list all)

@robscott, (Others are interested and happy to help review, will add more as we go)

8. 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)

• https://docs.google.com/document/d/1X7vLR3Zq-ZIkVp8m23_kHQ96rLxRJIxgheQByacs1T4/edit?tab=t.0#bookmark=id.4lmgx9y1ezjr

• https://docs.google.com/document/d/1eg-YjOHaQ7UD28htdNxBR3zufebozXKyI28cl2E11tU/edit?tab=t.0#bookmark=id.55cd9wmhpl0n

• Gateway For Mesh - Status, Gaps and goals for 2025 #3566

• Gather use cases for service accounts as selectors network-policy-api#274

• https://sched.co/1uSNk

[youngnick]

HTTP Auth* in Gateway API for north/south use cases

1. Describe the proposed feature

Make forward progress on some sort of construct to describe authentication and/or authorization for north-south use cases.

We've already got a provisional GEP for this at https://gateway-api.sigs.k8s.io/geps/gep-1494/ (#1494).

2. Why is this feature important for Gateway API?

This is a table-stakes feature for most Ingress implementations, and the lack of a solution here is a barrier to Gateway API adoption.

Note that this stage covers actually moving this to experimental.

The current option discussed is support for Envoy's ext_auth API, which can be added to other proxies as well.

This option would allow for multiple methods of Authentication and/or Authorization to be used, because of how ext_auth forwards request details off to another service.

This proposal will only add to Gateway and/or HTTPRoute, with a Policy used as a last resort.

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

This is easily supportable for Envoy implementations, other implementations will need to implement the API, which also involves writing down the API specification.

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, but I know that other folks, (@kflynn, at least) are also interested.

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)

We've talked about this already quite a bit:

• The existing GEP is GEP: Gateway/HTTPRoute level authentication #1494
• @kflynn summarized our Paris discusion: GEP: Gateway/HTTPRoute level authentication #1494 (comment)
• a Provisional GEP has been merged at https://gateway-api.sigs.k8s.io/geps/gep-1494/

[youngnick]

Note that I don't think that we will be able to use the same mechanisms for north-south and east-west authentication and authorization, as the mechanisms, underlying infrastructure, and overall designs are just too different. At best, I think we can try and keep some things similar, although that's not guaranteed.

[kflynn]

Definitely interested.

[kflynn]

External Gateway Controllers

Chihiro and Ian want a way for out-of-cluster load balancers to be able to usefully participate in a GAMMA-compliant mesh

Describe the proposed feature

Some cluster providers (GKE and Azure at least) are looking at moving the proxies that actually implement ingress controller / API gateway functionality out of the cluster, but they'd still like them to be able to participate in the mesh inside the cluster.

Why is this feature important for Gateway API?

The cluster providers will be doing this irrespective of whether Gateway API follows along (thanks, cloud providers! 😂). It will be better for both platform engineers and for mesh providers if we provide a cloud-agnostic way to support the external ingress proxy participating in the mesh; otherwise, either the hop from the external ingress proxy to the first meshed workload will be unencrypted, or the cloud provider will provide some cloud-provider-specific (and probably mesh-specific) solution.

How broadly supportable would this feature be?

It's conceptually straightforward to think about extending mesh mTLS keying to cover an external ingress proxy, so I would expect that at least the mTLS-based meshes would be able to implement this feature as long as we're careful in its design (sorry, Cilium!).

(Note that "conceptually straightforward" does not imply "there are no challenges". 🙂)

Do you have sufficient time to lead the development of this feature

Yes.

Do you have reviewers ready to support the progress of this feature?

Yup, at least @robscott and @mikemorris.

Are there any relevant links for previous discussions about this topic in Gateway API?

We discussed it in Paris in two very active discussions; those are summarized in the Gateway API meeting notes.

#1478 is sufficiently related that part of work on this proposed feature may involve furthering it as well.

[kflynn]

Default Gateways

Ana wants a concept of a default Gateway

Describe the proposed feature

Ana is likely to be frustrated by... well, many things about Gateway API, really, but one in particular is the need to always explicitly specify the parent Gateway of every route she ever creates. In a great many cases, Ana probably really just wants to say "here's a Route from the outside world to my workload"; giving her a way to do that is a concrete small step we can take to make her life easier when using Gateway API.

Why is this feature important for Gateway API?

If Ana wants to use Gateway API, that's a great way to improve adoption. Right now, though, the folks that I talk to who embody Ana tend to find Gateway API frustrating, partly because of the verbosity of the API, even while the folks that I talk to who embody Chihiro tend to welcome the control that Gateway API provides them. I think that there are ways we can tweak our balancing act here to be better for Ana.

How broadly supportable would this feature be?

This feature should be supportable by any N/S implementation -- all such implementations have to be able to select Gateways at present, and this feature is a modification to the logic by which they do so.

Do you have sufficient time to lead the development of this feature

Yes.

Do you have reviewers ready to support the progress of this feature?

Yup, at least @shaneutt.

Are there any relevant links for previous discussions about this topic in Gateway API?

#3385 has extensive discussion, but no resolution.