v1.4.0 Release-Cycle: Experimental Features

[shaneutt]

Note: This discussion is now locked, as scoping for v1.4.0 has concluded.

📣 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)
   @mikemorris / @kflynn

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

[mikemorris]

You can add me as a reviewer!

[kflynn]

You can add me as a reviewer too. 🙂

[shadialtarsha]

Thanks guys

[shaneutt]

Voting has concluded, and due to capacity reasons this feature unfortunately was not accepted for v1.4.0. You can see the relevant announcement here. We plan to try and recruit more contributors as reviewers in hopes of increasing our capacity for future releases so we can accept more items.

What this essentially boils down to is that we can't prioritize this feature for the moment. That doesn't mean you can't try to move it forward if you want, just that reviews for PRs related to this wont get priority at this time. We recommend reaching out to interested folks in the community to gather more support, and re-submit this feature for the upcoming v1.5.0 release. If you have any questions or concerns, or need any other kind of support please reach out to the maintainers!

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

[shaneutt]

Voting has concluded, and due to capacity reasons this feature unfortunately was not accepted for v1.4.0. You can see the relevant announcement here. We plan to try and recruit more contributors as reviewers in hopes of increasing our capacity for future releases so we can accept more items.

What this essentially boils down to is that we can't prioritize this feature for the moment. That doesn't mean you can't try to move it forward if you want, just that reviews for PRs related to this wont get priority at this time. We recommend reaching out to interested folks in the community to gather more support, and re-submit this feature for the upcoming v1.5.0 release. If you have any questions or concerns, or need any other kind of support please reach out to the maintainers!

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

[shaneutt]

Voting has concluded, and due to capacity reasons this feature unfortunately was not accepted for v1.4.0. You can see the relevant announcement here. We plan to try and recruit more contributors as reviewers in hopes of increasing our capacity for future releases so we can accept more items.

What this essentially boils down to is that we can't prioritize this feature for the moment. That doesn't mean you can't try to move it forward if you want, just that reviews for PRs related to this wont get priority at this time. We recommend reaching out to interested folks in the community to gather more support, and re-submit this feature for the upcoming v1.5.0 release. If you have any questions or concerns, or need any other kind of support please reach out to the maintainers!

[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

[mikemorris]

Discussed as likely eligible for inclusion in the ingress-nginx feature gap bucket https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/

[shaneutt]

This has been accepted for v1.4.0. See here for more details and follow up on #91 for any continued conversations.

[LiorLieberman]

Support East-West (E/W) Authorization

1. Provide a link to the Issue for the proposed feature (required): GEP: 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

[howardjohn]

Existing service meshes do a absolutely massive amount of things. Gateway API today is currently focused on the networking and traffic management aspect of it, where mesh users can use already do an effective job of only using portable APIs.

I don't actually agree with a goal that a mesh user should be able to exclusively use gateway API to solve all mesh use cases in a portable manner. If that is we have only really solved 25% of the total surface of the problem IMO, and solving authz only really solved about 25%.

I'm not necessarily opposed to adding an auth API (though I am cautiously skeptical as I worry it will be a lowest-common-denominator result) but just focusing on the broader goal of mesh here.

[kflynn]

Let me reiterate:

While I definitely agree that this is an important topic and we should dig into it...

"A critical gap to cover" is very much compatible with backing up a step rather than trying to go straight to an API surface. Let's understand the gap, then do the API.

[robscott]

I don't actually agree with a goal that a mesh user should be able to exclusively use gateway API to solve all mesh use cases in a portable manner

I don't think anyone's arguing for that. Instead I'd argue that a majority of mesh users should be able to use Gateway API to configure their mesh of choice without needing any implementation-specific APIs. I agree that there's a very long list of mesh capabilities, but my guess is that the vast majority of mesh users only use a small subset of those capabilities. If I were to guess, I'd assume that auth and mTLS are 2 of the most common features used with any mesh, and these are significant gaps in GW API today.

"A critical gap to cover" is very much compatible with backing up a step rather than trying to go straight to an API surface. Let's understand the gap, then do the API.

Agree. That's built into the GEP process. Adding this to scope for v1.4 means that we're going to try to make progress on this, with the first step of this or any other GEP to be to agree to the set of requirements we're trying to solve for.

[mikemorris]

Instead of looking at an API for E/W auth, look at what the GAMMA meshes do and don't agree on for E/W identity, E/W auth, and define use cases, gaps, and commonalities.

Strongly agreed with @kflynn that a [important and very useful] first step here would be a provisional GEP covering this background, not jumping directly into an experimental API design.

[shaneutt]

This has been accepted for v1.4.0. See here for more details, and please follow up on the #3779 to continue conversations.

[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]

There's also a summary of our discussion about this in London in the Gateway API meeting notes (scroll down to below the 8 April meeting minutes).

[mikemorris]

Discussed as likely eligible for inclusion in the ingress-nginx feature gap bucket https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/

[shaneutt]

This has been accepted for v1.4.0. See here for more details, and please follow up on the #1494 to continue conversations.

[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

Note: the most likely immediate outcome here is a definitional/provisional GEP to define the problem, rather than an immediate API-change proposal.

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 London in two very active discussions; those are summarized in the Gateway API meeting notes (scroll down to below the 8 April meeting minutes).

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

[mikemorris]

I am actually curious if there's any chance this could be designed in an extensible enough way to support integration with Cilium too (we do have a use case for that on Azure).

[kflynn]

I am also curious. 🙂

To my way of thinking, Cilium is different enough that we may to consider this in two phases, but we should certainly be thinking about Cilium here.

[LiorLieberman]

Plus 1 - I think thats a very interesting one and curios to see what this effort would yield. Also interested in what we can do with cilium and whats our take as a whole regarding this two-phase approach (which I dont dislike).

+1 - this is a really interesting one, and I’m curious to see what this effort would yield. I’m also interested in how support for cilium will eventually look like (personally - I do not need the answer right now). Is there any guidance on how we approach features that may not be universally implementable at their first iteration?

[shaneutt]

This has been accepted for v1.4.0. See here for more details, and please follow up on the #3792 to continue conversations.

[kflynn]

Default Gateways

Ana wants a concept of a default Gateway

Note: the most likely immediate outcome here is a definitional/provisional GEP to define the problem, rather than an immediate API-change proposal.

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.

[mlavacca]

Happy to be a reviewer for this one.

[shaneutt]

This has been accepted for v1.4.0. See here for more details, and please follow up on the #3793 to continue conversations.

[xtineskim]

gRPC Timeouts

(copy pasta of last 1.3 scoping)

1. Describe the proposed feature
   adding gRPC timeouts to GRPCRoute, similar to how HTTPRoute has timeouts

2. Why is this feature important for Gateway API?
   To keep xRoutes on par with each other

3. How broadly supportable would this feature be? (Look at Envoy, HAProxy, and NGINX as a baseline)
   Various implementations have some method of implementing gRPC timeouts

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)
   GRPCRoute timeout - GEP-3139 #3219

6. Do you have reviewers ready to support the progress of this feature? (list all)
   @mikemorris and @kflynn 😃

Like @mikemorris mentioned, it would be great to complete this in tandem with gRPC retries 😁

[shaneutt]

Voting has concluded, and due to capacity reasons this feature unfortunately was not accepted for v1.4.0. You can see the relevant announcement here. We plan to try and recruit more contributors as reviewers in hopes of increasing our capacity for future releases so we can accept more items.

What this essentially boils down to is that we can't prioritize this feature for the moment. That doesn't mean you can't try to move it forward if you want, just that reviews for PRs related to this wont get priority at this time. We recommend reaching out to interested folks in the community to gather more support, and re-submit this feature for the upcoming v1.5.0 release. If you have any questions or concerns, or need any other kind of support please reach out to the maintainers!

[goat-ssh]

ExtensionRefs for TLSRoute

1. Provide a link to the Issue for the proposed feature (required) ExtensionRefs for TLSRoute #3635

2. Describe the proposed feature
   This proposal seeks to extend the rules.backendRefs.filters.extensionRefs functionality, currently available for HTTPRoute in the Gateway API, to TLSRoute. The extensionRefs filter allows referencing implementation-specific resources, such as Traefik’s IPAllowList Middleware, to apply custom filtering logic to traffic routed through a Gateway.
   For TLSRoute, this would enable attaching custom filters (e.g., Traefik’s IPAllowList Middleware) to control which client IPs can access a TLS-based backend service without modifying the Gateway’s loadBalancerSourceRanges. The proposed change would involve updating the TLSRoute specification to include a filters field under rules.backendRefs, mirroring the structure in HTTPRoute

3. Why is this feature important for Gateway API?
   Extending extensionRefs to TLSRoute would:

• Enhance Flexibility: Allow route-level customization for TLS traffic, aligning TLSRoute with HTTPRoute’s capabilities.
• Improve Security: Enable precise access control (e.g., IP allowlisting) without modifying global Gateway settings.
• Unlock Use Cases: Support non-HTTP TLS workloads (e.g., secure IoT protocols, databases) that require custom filtering.
• Maintain Consistency: Ensure parity between HTTPRoute and TLSRoute in terms of extensibility, making the API more predictable.

4. How broadly supportable would this feature be?
   Probably all would benefit.
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)
   Not really.
6. Do you have reviewers ready to support the progress of this feature? (list all)
   No idea
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)

[shaneutt]

Voting has concluded, and due to capacity reasons this feature unfortunately was not accepted for v1.4.0. You can see the relevant announcement here. We plan to try and recruit more contributors as reviewers in hopes of increasing our capacity for future releases so we can accept more items.

What this essentially boils down to is that we can't prioritize this feature for the moment. That doesn't mean you can't try to move it forward if you want, just that reviews for PRs related to this wont get priority at this time. We recommend reaching out to interested folks in the community to gather more support, and re-submit this feature for the upcoming v1.5.0 release. If you have any questions or concerns, or need any other kind of support please reach out to the maintainers!

[arihantg]

Client Ip based session persistence

1. Support for ClientIp based session persistence
   

2. Describe the proposed feature
   SessionPersistence should support client IP address mode. With this persistence method client will stick to the same BE for the configurable duration of time (Absolutetimeout). User should have an option to set IPMask as well which can be applied on client ip to persist clients from a subnet to stick to the same BE.

3. Why is this feature important for Gateway API?
   This will keep session persistence fields in a single object.

4. How broadly supportable would this feature be?
   various implementations currently support it. via policy , local object references and seesion affinity.

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?
   yes

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

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)

[sunjayBhatia]

just a conformance reviewer but happy to help review this one

[shaneutt]

This has been accepted for v1.4.0. See here for more details, and please follow up on the #3798 to continue conversations.

[lianglli]

HTTP Streaming Filter

1. Provide a link to the Issue for the proposed feature (required)
   GEP: Enable or disable HTTP Streaming of request or response

2. Describe the proposed feature
   Provide a way to enable or disable HTTP Streaming of request or response in a HTTPRoute.

3. Why is this feature important for Gateway API?

   Large file or message:

   • When HTTP Streaming of client request body for a hostname is enabled, the gateway will send request body to the upstream immediately as it is received from the client.
   • When HTTP Streaming of upstream response for a hostname is enabled, the gateway will pass response to a client synchronously, immediately as it is received from the upstream.

   MCP:

   • For the HTTP SSE (version 2024-11-05) endpoint, the gateway will send response to an mcp client synchronously.
   • For the Streamable HTTP (version 2025-03-26) endpoint , the gateway will send request to an mcp server immediately as it is received from an mcp client and send response to an mcp client synchronously as it is received from an mcp server.

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

   • NGINX supports it using the proxy_request_buffering directive and the proxy_buffering directive.

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: Enable or disable HTTP Streaming of request or response

[mikemorris]

This looks like it's relevant to the needs of https://gateway-api-inference-extension.sigs.k8s.io/, but possibly more broadly applicable? cc @LiorLieberman

[shaneutt]

Voting has concluded, and due to capacity reasons this feature unfortunately was not accepted for v1.4.0. You can see the relevant announcement here. We plan to try and recruit more contributors as reviewers in hopes of increasing our capacity for future releases so we can accept more items.

What this essentially boils down to is that we can't prioritize this feature for the moment. That doesn't mean you can't try to move it forward if you want, just that reviews for PRs related to this wont get priority at this time. We recommend reaching out to interested folks in the community to gather more support, and re-submit this feature for the upcoming v1.5.0 release. If you have any questions or concerns, or need any other kind of support please reach out to the maintainers!