Summary
ee-apps currently has 4 charts that render Gateway API HTTPRoute resources:
charts/cloudevents-server
charts/dl
charts/publisher
charts/tibuild-v2
These 4 charts all use the same HTTPRoute template shape, and they all drop rule-level fields other than matches and filters.
That means users cannot actually configure spec.rules[].timeouts, even if they put it in values. This is already causing operational friction for large streaming/download routes where Envoy/Gateway request timeout needs to be disabled or tuned.
Problem
Current templates only preserve:
spec.parentRefs
spec.hostnames
spec.rules[].matches
spec.rules[].filters
- a hardcoded single
backendRef pointing to the chart service
They do not preserve other valid rule-level fields such as:
spec.rules[].timeouts
spec.rules[].name
- future/extended fields added by Gateway API implementations
So values like this:
httpRoute:
enabled: true
rules:
- matches:
- path:
type: PathPrefix
value: /
timeouts:
request: 0s
render into an HTTPRoute without the timeouts block.
Evidence
Affected templates:
charts/cloudevents-server/templates/httproute.yaml
charts/dl/templates/httproute.yaml
charts/publisher/templates/httproute.yaml
charts/tibuild-v2/templates/httproute.yaml
All 4 templates currently have the same pattern:
rules:
{{- range .Values.httpRoute.rules }}
{{- with .matches }}
- matches:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .filters }}
filters:
{{- toYaml . | nindent 8 }}
{{- end }}
backendRefs:
- name: {{ $fullName }}
port: {{ $svcPort }}
weight: 1
{{- end }}
A quick render check confirms timeouts is silently dropped for all 4 charts.
Why this matters
For routes serving large downloads, uploads, or long-lived streaming responses, default proxy/gateway request timeouts are often wrong.
A concrete case is dl: we needed to set HTTPRoute.spec.rules[].timeouts.request: 0s to avoid large artifact downloads being cut off behind Envoy Gateway.
Because the chart template cannot render timeouts, downstream manifests had to work around it outside the chart instead of using normal chart values.
Proposed fix
Standardize all in-house HTTPRoute chart templates to preserve arbitrary rule-level fields while still owning the backend service reference.
A practical pattern is:
rules:
{{- range .Values.httpRoute.rules }}
- {{- toYaml (omit . "backendRefs") | nindent 2 }}
backendRefs:
- name: {{ $fullName }}
port: {{ $svcPort }}
{{- end }}
This keeps the chart-controlled backend wiring, while allowing values to specify:
timeouts
name
matches
filters
- future rule-level fields without more chart changes
It would also be good to standardize extra metadata support across these charts:
httpRoute.labels
httpRoute.annotations
Acceptance criteria
- All 4 charts above can render
httpRoute.rules[].timeouts.request.
- Existing
matches and filters behavior remains compatible.
- Charts continue to own the backend service reference instead of requiring callers to specify it.
- Add/extend chart tests to cover a rule containing
timeouts.request: 0s.
- Prefer one shared implementation style across all
ee-apps charts with HTTPRoute support.
Nice to have
- Add a small doc/example in each chart values file showing a long-lived route example with:
Summary
ee-appscurrently has 4 charts that render Gateway APIHTTPRouteresources:charts/cloudevents-servercharts/dlcharts/publishercharts/tibuild-v2These 4 charts all use the same
HTTPRoutetemplate shape, and they all drop rule-level fields other thanmatchesandfilters.That means users cannot actually configure
spec.rules[].timeouts, even if they put it in values. This is already causing operational friction for large streaming/download routes where Envoy/Gateway request timeout needs to be disabled or tuned.Problem
Current templates only preserve:
spec.parentRefsspec.hostnamesspec.rules[].matchesspec.rules[].filtersbackendRefpointing to the chart serviceThey do not preserve other valid rule-level fields such as:
spec.rules[].timeoutsspec.rules[].nameSo values like this:
render into an
HTTPRoutewithout thetimeoutsblock.Evidence
Affected templates:
charts/cloudevents-server/templates/httproute.yamlcharts/dl/templates/httproute.yamlcharts/publisher/templates/httproute.yamlcharts/tibuild-v2/templates/httproute.yamlAll 4 templates currently have the same pattern:
A quick render check confirms
timeoutsis silently dropped for all 4 charts.Why this matters
For routes serving large downloads, uploads, or long-lived streaming responses, default proxy/gateway request timeouts are often wrong.
A concrete case is
dl: we needed to setHTTPRoute.spec.rules[].timeouts.request: 0sto avoid large artifact downloads being cut off behind Envoy Gateway.Because the chart template cannot render
timeouts, downstream manifests had to work around it outside the chart instead of using normal chart values.Proposed fix
Standardize all in-house
HTTPRoutechart templates to preserve arbitrary rule-level fields while still owning the backend service reference.A practical pattern is:
This keeps the chart-controlled backend wiring, while allowing values to specify:
timeoutsnamematchesfiltersIt would also be good to standardize extra metadata support across these charts:
httpRoute.labelshttpRoute.annotationsAcceptance criteria
httpRoute.rules[].timeouts.request.matchesandfiltersbehavior remains compatible.timeouts.request: 0s.ee-appscharts withHTTPRoutesupport.Nice to have