feat: Gateway-API as an alternative to the Ingress in eight charts

Group 1 of the #114 sweep: the charts that render exactly one Ingress object
and set no behaviour-bearing nginx annotation - bentopdf, garage, patchmon,
rallly, searxng, sure, urlaubsverwaltung, voucher-vault.

Each gets the form the pilot (cyberchef, PR #115) fixed and template-chart
carries: an httpRoute block (enabled/parentRefs/hostnames, off by default), a
template rendering ONLY an HTTPRoute with parentRefs - no Gateway, no
gatewayClassName, no Certificate, no implementation-specific policy object -
render aborts on both modes at once (naming both value paths), on an empty
parentRefs and on a missing hostname, empty hostnames meaning [ingress.domain],
a schema entry closed against unknown keys with an open parentRef definition,
and a NOTES.txt that names the active mode and what the mode costs.

Minor, additive, defaults unchanged: `helm template` with each chart's CI
values is byte-identical to origin/main for seven of the eight, and for sure
identical in every rendered value (the diff is two YAML comment lines).

Three findings that were not in the plan, each argued in the file it changes:

  sure derived RAILS_ASSUME_SSL/RAILS_FORCE_SSL from ingress.enabled alone.
  Gateway mode sets that false by construction while TLS is still terminated at
  the Gateway, so both flags would have gone false: insecure cookies, no HSTS,
  http:// links, with a Ready pod and a working UI as the only symptom. They now
  read sure.publishedOverTls (ingress.enabled OR httpRoute.enabled), which is
  ingress.enabled while httpRoute.enabled is false - hence still Minor.

  garage claimed, in its Ingress template and its schema, that nothing outside
  that template reads ingress.domain. The HTTPRoute reads it, so the claim now
  holds only while both modes are off. Corrected rather than left standing.

  garage also depends on an upload limit it does not set: its annotations
  comment tells the operator to set proxy-body-size: "0" because ingress-nginx
  truncates S3 uploads at 1 MB. proxy-body-size has no Gateway-API counterpart,
  so its Gateway-mode NOTES prints that the limit is the Gateway's. README's
  list of affected charts named five and now names garage as a sixth.

clusterIssuer needed no change in any of the eight: its only required() sits
inside the Ingress template behind ingress.enabled, the same no-op the pilot
found. Annotation guidance that stops applying in Gateway mode moved into the
Gateway branch of NOTES.txt for bentopdf (X-Robots-Tag) and searxng
(forward-auth).

CI: one render overlay per chart under ci/httproute/, so the assertion is not
vacuum-green - ci/run-httproute-match-test.sh goes from 4 held assertions over
2 charts to 20 over 10. The install-test fixtures stay in Ingress mode: the
install runs one configuration per chart, cyberchef already pays that price
against the real Gateway-API CRDs, and for garage the Ingress is the only place
its Service port is referenced by NAME.

Not proven, by construction: that traffic flows. No Gateway controller runs in
CI. Not run locally either: k3d, Docker, Trivy.

Part of #114

sure/Chart.yaml

@@ -5,7 +5,7 @@ icon: https://raw.githubusercontent.com/we-promise/sure/main/public/android-chro
 
 type: application
 
-version: 1.0.0+up0.7.4
+version: 1.1.0+up0.7.4
 appVersion: "0.7.4"
 
 maintainers:

sure/templates/NOTES.txt

@@ -2,11 +2,16 @@
 {{- $webStartup := fromYaml (include "sure.webStartupProbe" .Values.sure.web.startupProbe) -}}
 {{- $workerStartup := fromYaml (include "sure.workerStartupProbe" .Values.sure.worker.startupProbe) -}}
 {{- $workerLiveness := fromYaml (include "sure.workerLivenessProbe" .Values.sure.worker.livenessProbe) -}}
+{{- $httpRoute := .Values.httpRoute | default dict -}}
+{{- $hostnames := $httpRoute.hostnames | default list -}}
+{{- if not $hostnames -}}
+{{- $hostnames = list .Values.ingress.domain -}}
+{{- end -}}
 Sure {{ .Chart.AppVersion }} — release {{ .Release.Name }} in namespace {{ .Release.Namespace }}.
 
 {{- if .Values.ingress.enabled }}
 
-ACCESS
+ACCESS — INGRESS MODE (ingress.enabled: true, httpRoute.enabled: false)
   https://{{ .Values.ingress.domain }}
 
   The certificate is requested by cert-manager through the "{{ .Values.ingress.clusterIssuer }}"
@@ -16,17 +21,62 @@ ACCESS
 
   The first account created on a fresh instance becomes the super admin — sign
   in yourself before handing the URL to anyone.
+{{- else if $httpRoute.enabled }}
+
+ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)
+{{- range $hostnames }}
+  https://{{ . }}
+{{- end }}
+
+  The first account created on a fresh instance becomes the super admin — sign
+  in yourself before handing the URL to anyone.
+
+  This release renders an HTTPRoute ({{ .Release.Name }}-{{ .Chart.Name }}-httproute) and NOTHING else
+  of the routing path — no Gateway, no class, no Certificate. Three things
+  therefore belong to the cluster and not to this chart:
+
+    1. The Gateway-API CRDs. Without them this install would have failed.
+    2. The Gateway named in httpRoute.parentRefs
+{{- range $httpRoute.parentRefs }}
+         {{ .name }}{{ if .namespace }} in namespace {{ .namespace }}{{ end }}{{ if .sectionName }}, listener {{ .sectionName }}{{ end }}
+{{- end }}
+       must exist AND its listener must allow routes from this namespace
+       ({{ .Release.Namespace }}) in allowedRoutes. A rejected attachment shows
+       up only in the route's status:
+
+         kubectl -n {{ .Release.Namespace }} get httproute {{ .Release.Name }}-{{ .Chart.Name }}-httproute -o yaml
+
+       Read status.parents[].conditions — "Accepted: True" and
+       "ResolvedRefs: True" is a working attachment. An empty status means no
+       controller has looked at the route at all.
+    3. The TLS certificate for the hostname, on the Gateway's listener. This is
+       the one to get right here: the chart renders RAILS_ASSUME_SSL and
+       RAILS_FORCE_SSL as "true" in this mode, i.e. Rails TRUSTS the forwarded
+       scheme, sets secure cookies and sends HSTS. A Gateway listener that is
+       plain HTTP would therefore hand out cookies the browser never returns.
+       ingress.clusterIssuer is NOT used and not required — the chart renders
+       no Certificate, so there is no tls-{{ .Release.Name }}-{{ .Chart.Name }}-ingress secret.
+
+  APP_DOMAIN, WEBAUTHN_RP_ID and WEBAUTHN_ALLOWED_ORIGINS still follow
+  ingress.domain ({{ .Values.ingress.domain }}), not httpRoute.hostnames. Passkeys are bound to
+  the relying party id, so publishing under a name that ingress.domain does not
+  carry gives you passkeys registered against the wrong party — and changing
+  ingress.domain afterwards invalidates every credential already registered.
+
+  ingress.annotations is inert in this mode: the Gateway API has no annotation
+  channel. Nothing this chart needs lives there.
 {{- else }}
 
-ACCESS — NO INGRESS
-  ingress.enabled is false, so this release has no Ingress and no certificate.
+ACCESS — NEITHER INGRESS NOR HTTPROUTE
+  ingress.enabled and httpRoute.enabled are both false, so this release has no
+  Ingress, no HTTPRoute and no certificate.
   ingress.domain is still required: it becomes APP_DOMAIN (the host in every
   mail link) and the WebAuthn relying party the app binds passkeys to. Reach
   the instance inside the cluster with
 
     kubectl -n {{ .Release.Namespace }} port-forward svc/{{ .Release.Name }}-{{ .Chart.Name }}-service 8080:80
 
-  and open http://localhost:8080. With the Ingress off the chart also renders
+  and open http://localhost:8080. With nothing published the chart also renders
   RAILS_ASSUME_SSL and RAILS_FORCE_SSL as "false", which is what makes that
   plain-HTTP session able to log in at all; mail links still point at
   https://{{ .Values.ingress.domain }}/.
@@ -35,7 +85,7 @@ ACCESS — NO INGRESS
 SCALED TO ZERO
   {{ if .Values.scaleDown }}scaleDown: true{{ else }}sure.replicas: 0{{ end }} — the StatefulSet runs with replicas: 0, so neither the web nor
   the worker process is running. PVC, Secrets, Service{{ if .Values.ingress.enabled }}, Ingress and the
-  certificate stay{{ else }} stay{{ end }} in place; set it back and upgrade to bring both containers up.
+  certificate stay{{ else if $httpRoute.enabled }}, and the HTTPRoute stay{{ else }} stay{{ end }} in place; set it back and upgrade to bring both containers up.
 {{ end }}
 WHAT THE THREE 1PASSWORD ITEMS MUST CONTAIN
   The chart creates OnePasswordItem CRs; the operator turns each into a

sure/templates/_helpers.tpl

@@ -318,6 +318,46 @@ comes from.
 {{- include "sure.resources" $merged -}}
 {{- end -}}
 
+{{/*
+Is this release published through a TLS-terminating proxy at all? Returns the
+string "true" or "false", for use as an environment variable value.
+
+Input: the root context.
+
+ONE PLACE, BECAUSE THE WRONG ANSWER IS INVISIBLE (Gitea #114)
+
+RAILS_ASSUME_SSL and RAILS_FORCE_SSL used to be rendered from ingress.enabled
+directly. That was correct while an Ingress was the only way this chart could
+publish anything. With the Gateway-API mode it stopped being correct in exactly
+one configuration - and that configuration is the whole point of the new mode:
+httpRoute.enabled: true forces ingress.enabled: false (the two are mutually
+exclusive, the render aborts otherwise), while TLS is still terminated in front
+of the app, now at the Gateway's listener. Read from ingress.enabled alone, both
+flags would have come out "false" there, and Rails would then
+
+  - not trust the X-Forwarded-Proto the Gateway sends, so it builds absolute
+    URLs - mail links, OIDC redirects - as http://,
+  - hand out session cookies without the Secure attribute, over a connection
+    that is in fact TLS, and
+  - send no HSTS header.
+
+None of that fails. The pod goes Ready, the UI works, and the only way to
+notice is to look at a Set-Cookie header. So the question is asked once, here,
+and both flags read the answer.
+
+With httpRoute.enabled at its default of false this expression IS
+ingress.enabled, which is why adding it changes nothing for an existing
+release: `helm template` with chart defaults renders byte-identically.
+*/}}
+{{- define "sure.publishedOverTls" -}}
+{{- $httpRoute := .Values.httpRoute | default dict -}}
+{{- if or .Values.ingress.enabled $httpRoute.enabled -}}
+true
+{{- else -}}
+false
+{{- end -}}
+{{- end -}}
+
 {{/*
 The environment both containers share: the same image, the same database, the
 same Redis, the same secrets. Only the command differs.
@@ -358,16 +398,30 @@ probe on "/" reach the database at all (see values.yaml).
   value: "/tmp/home"
 - name: PORT
   value: "3000"
-# Sure's production.rb defaults BOTH of these to true. The chart renders them
-# explicitly from ingress.enabled instead: with the Ingress terminating TLS,
-# assume_ssl makes Rails treat the forwarded request as secure (so force_ssl
-# adds HSTS and secure cookies without redirecting), while without an Ingress
-# both have to be off - a port-forwarded plain-HTTP session would otherwise
-# either be redirected to https or hand out cookies the browser never returns.
+{{- /*
+Sure's production.rb defaults BOTH of these to true. The chart renders them
+explicitly from whether this release is published through a TLS-terminating
+proxy at all - ingress.enabled OR httpRoute.enabled, see
+"sure.publishedOverTls" above for why that OR is load-bearing and why reading
+ingress.enabled alone was a silent defect in Gateway mode.
+
+With a proxy in front, assume_ssl makes Rails treat the forwarded request as
+secure (so force_ssl adds HSTS and secure cookies without redirecting); with
+nothing in front both have to be off, or a port-forwarded plain-HTTP session is
+either redirected to https or handed cookies the browser never returns.
+
+A template comment and not a YAML one on purpose: this block is inside the
+define, so a "#" comment here is rendered INTO every manifest and every edit to
+it shows up as a diff in the deployed object. The emitted comment below is kept
+to the one line an operator reading `helm get manifest` needs.
+*/ -}}
+{{- $tls := include "sure.publishedOverTls" . }}
+# Rendered from ingress.enabled OR httpRoute.enabled (TLS is terminated by
+# whichever proxy publishes this release); both off means plain HTTP.
 - name: RAILS_ASSUME_SSL
-  value: "{{ .Values.ingress.enabled }}"
+  value: "{{ $tls }}"
 - name: RAILS_FORCE_SSL
-  value: "{{ .Values.ingress.enabled }}"
+  value: "{{ $tls }}"
 # Action Mailer builds absolute URLs from this host, and it is the fallback the
 # WebAuthn initializer uses when WEBAUTHN_RP_ID is unset.
 - name: APP_DOMAIN

sure/templates/sure.httproute.yaml

@@ -0,0 +1,99 @@
+{{/*
+The Gateway-API alternative to sure.ingress.yaml (Gitea #114). Form and
+reasoning: template-chart/templates/xxx.httproute.yaml and README, "Ingress and
+Gateway API".
+
+Only an HTTPRoute with parentRefs. No Gateway, no gatewayClassName, no
+Certificate, and no implementation-specific policy object - that subset looks
+identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is
+the whole reason the cluster's implementation can be swapped without touching
+this chart. Class and certificate therefore belong to the PLATFORM, on the
+Gateway and its listeners.
+
+ingress.clusterIssuer is meaningless here - this chart renders no Certificate
+in this mode - and it is not demanded either: its only required() sits inside
+sure.ingress.yaml, behind ingress.enabled.
+
+THE ONE THING THIS CHART NEEDED BEYOND THE ROUTE: HOW RAILS IS TOLD ABOUT TLS
+
+sure.commonEnv used to render RAILS_ASSUME_SSL and RAILS_FORCE_SSL from
+ingress.enabled alone, which was exactly right while an Ingress was the only
+way this release could be published. In Gateway mode ingress.enabled is false
+BY CONSTRUCTION - the two modes are mutually exclusive - while TLS is still
+terminated in front of the app, now at the Gateway's listener. Left as it was,
+a Gateway-mode install would have come up with both flags false: Rails would
+not trust the forwarded scheme, would hand out cookies without the Secure
+attribute, would send no HSTS and would build absolute links as http://. The
+pod goes Ready and the UI works, so nothing reports it - which is the class of
+failure this repository treats as a defect rather than a default.
+
+The flags therefore follow "is this release published through a TLS-terminating
+proxy at all" (sure.publishedOverTls in _helpers.tpl), which is
+ingress.enabled OR httpRoute.enabled. With httpRoute.enabled at its default of
+false that expression IS ingress.enabled, so nothing changes for an existing
+release - the behaviour only differs for a configuration that did not exist
+before. A port-forwarded plain-HTTP session still gets both flags false and can
+still log in.
+
+ingress.domain IS STILL REQUIRED, AND NOT BECAUSE OF THIS FILE
+
+Checked for this chart rather than copied: sure.commonEnv reads ingress.domain
+with its own required(), three times over - APP_DOMAIN, WEBAUTHN_RP_ID and
+WEBAUTHN_ALLOWED_ORIGINS. So domain is mandatory in every mode and the fallback
+below is never the only reader. Mind WEBAUTHN_RP_ID in particular when
+publishing under a new name: passkeys are bound to the relying party id, and
+changing it invalidates every registered credential. That is a reason to be
+careful with httpRoute.hostnames, which does NOT move the relying party id
+with it.
+*/}}
+{{- /*
+Null-safe like every other block this chart dereferences (#99): an override
+written without children - "httpRoute:" with the keys below it deleted - is
+YAML null, and `.Values.httpRoute.enabled` would abort the render with a nil
+pointer. An empty block means "chart defaults apply", and all three defaults
+are empty or false, so the whole block collapses to "no HTTPRoute".
+*/ -}}
+{{- $httpRoute := .Values.httpRoute | default dict -}}
+{{- if and $httpRoute.enabled .Values.ingress.enabled -}}
+{{- fail "ingress.enabled and httpRoute.enabled are both true - set exactly one of them. The Ingress and the HTTPRoute would publish the same Service under the same hostname over two different data paths, which is already a conflict at DNS level: one name, two addresses, and which one a client reaches is luck. A migration runs over a SECOND hostname (set httpRoute.hostnames explicitly while the Ingress keeps ingress.domain), never over parallel operation of both." -}}
+{{- end -}}
+{{- if $httpRoute.enabled -}}
+{{- $parentRefs := $httpRoute.parentRefs | default list -}}
+{{- if not $parentRefs -}}
+{{- fail "httpRoute.enabled is true but httpRoute.parentRefs is empty - an HTTPRoute without a parent attaches to no Gateway. It is created, it is schema-valid, and it routes NOTHING, with no event and no condition that says so; the only symptom is a hostname that does not answer. Name the cluster's Gateway, e.g. httpRoute.parentRefs: [{name: public, namespace: gateway}]." -}}
+{{- end -}}
+{{- /*
+One source of truth for the hostname: an empty httpRoute.hostnames means
+[ingress.domain], so the two cannot drift apart. See the header for what
+setting it explicitly does not move.
+*/ -}}
+{{- $hostnames := $httpRoute.hostnames | default list -}}
+{{- if not $hostnames -}}
+{{- $hostnames = list (required "A Domain/Host must be provided: set ingress.domain (used as the HTTPRoute's single hostname when httpRoute.hostnames is empty) or set httpRoute.hostnames explicitly" .Values.ingress.domain) -}}
+{{- end -}}
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: {{ .Release.Name }}-{{ .Chart.Name }}-httproute
+spec:
+  parentRefs:
+    {{- toYaml $parentRefs | nindent 4 }}
+  hostnames:
+    {{- toYaml $hostnames | nindent 4 }}
+  rules:
+    # The Ingress counterpart is `path: / , pathType: Prefix` on the one
+    # backend Service - the web container serves everything; the worker has no
+    # HTTP port and is never routed to. The port is the Service's port NUMBER
+    # and not its name ("http"): backendRefs takes a PortNumber, so unlike the
+    # Ingress this reference cannot be made by name and the 80 below has to
+    # track sure.service.yaml by hand.
+    # ci/run-httproute-match-test.sh is what holds that pair - it fails when a
+    # backendRef names a Service, or a port, the same render does not create.
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /
+      backendRefs:
+        - name: {{ .Release.Name }}-{{ .Chart.Name }}-service
+          port: 80
+{{- end }}

sure/values.schema.json

@@ -118,7 +118,7 @@
       "additionalProperties": false,
       "properties": {
         "enabled": {
-          "description": "Gates the Ingress template (issue #93) and decides whether the chart renders RAILS_ASSUME_SSL/RAILS_FORCE_SSL as true or false. It does NOT free ingress.domain: that value is also read for APP_DOMAIN, WEBAUTHN_RP_ID and WEBAUTHN_ALLOWED_ORIGINS and keeps its own required() there (guideline 12.1).",
+          "description": "Gates the Ingress template (issue #93). Mutually exclusive with httpRoute.enabled - the render aborts when both are true. It does NOT free ingress.domain: that value is also read for APP_DOMAIN, WEBAUTHN_RP_ID and WEBAUTHN_ALLOWED_ORIGINS and keeps its own required() there (guideline 12.1). Since Gitea #114 it no longer decides the TLS flags on its own either: RAILS_ASSUME_SSL/RAILS_FORCE_SSL follow ingress.enabled OR httpRoute.enabled, because in Gateway mode TLS is terminated at the Gateway while this value is false by construction.",
           "type": "boolean"
         },
         "clusterIssuer": {
@@ -131,13 +131,42 @@
           "type": ["string", "null"]
         },
         "annotations": {
-          "description": "Extra Ingress annotations, merged with the cert-manager annotation the chart always sets. Free-form keys by nature, so this object stays open.",
+          "description": "Extra Ingress annotations, merged with the cert-manager annotation the chart always sets. Free-form keys by nature, so this object stays open. No counterpart in Gateway mode: the Gateway API has no annotation channel, so these are gone when httpRoute.enabled is used instead.",
           "type": "object"
         }
       }
+    },
+    "httpRoute": {
+      "description": "Gateway-API alternative to the Ingress (Gitea #114). Mutually exclusive with ingress.enabled - the render aborts when both are true. The chart renders only an HTTPRoute with parentRefs; class and certificate sit on the Gateway and belong to the platform. The Gateway-API CRDs must be present in the cluster, because the chart cannot detect them. This value also feeds RAILS_ASSUME_SSL/RAILS_FORCE_SSL - see ingress.enabled.",
+      "type": "object",
+      "additionalProperties": false,
+      "properties": {
+        "enabled": {
+          "type": "boolean"
+        },
+        "parentRefs": {
+          "description": "The Gateway(s) the route attaches to. Required while httpRoute.enabled is true, enforced by required()-equivalent in the template (an empty list aborts the render) - a JSON Schema \"required\" cannot do it, because the key ships as an empty list and is therefore present. Entries are the Gateway API's ParentReference and are passed through unchanged.",
+          "type": "array",
+          "items": {
+            "$ref": "#/definitions/parentRef"
+          }
+        },
+        "hostnames": {
+          "description": "Empty means [ingress.domain], so the hostname has a single source of truth. A hostname set here does not move WEBAUTHN_RP_ID, APP_DOMAIN or WEBAUTHN_ALLOWED_ORIGINS, which keep following ingress.domain - and changing the relying party id invalidates every registered passkey.",
+          "type": "array",
+          "items": {
+            "type": "string"
+          }
+        }
+      }
     }
   },
   "definitions": {
+    "parentRef": {
+      "description": "A Gateway API ParentReference, passed verbatim into HTTPRoute.spec.parentRefs. Deliberately left OPEN (no additionalProperties: false), for the same reason probes and security contexts are: Kubernetes owns this schema, the Gateway API adds fields to it across releases, and a closed list here would reject a field only upstream knows about. What the chart can assert is that \"name\" is there - it is required by the API and a reference without it attaches to nothing, which is the silent failure this chart aborts the render over.",
+      "type": "object",
+      "required": ["name"]
+    },
     "resources": {
       "description": "May be null / empty: the chart then falls back to its default requests and computed limits (issue #99) instead of rendering a container without resource accounting.",
       "type": ["object", "null"],

sure/values.yaml

@@ -299,14 +299,78 @@ ingress:
   # up with WEBAUTHN_RP_ID="" and register passkeys against the wrong relying
   # party - rendered cleanly, pod green.
   #
-  # ingress.enabled also decides how the app is told about TLS: enabled renders
-  # RAILS_ASSUME_SSL=true and RAILS_FORCE_SSL=true (the Ingress terminates TLS,
-  # so Rails must trust that and may set secure cookies and HSTS), disabled
-  # renders both as "false" so a plain-HTTP port-forward can log in at all.
+  # Mutually exclusive with httpRoute.enabled below (Gitea #114): with both
+  # true the render aborts, naming both values.
+  #
+  # HOW THE APP IS TOLD ABOUT TLS NO LONGER HANGS ON THIS VALUE ALONE (#114).
+  # RAILS_ASSUME_SSL and RAILS_FORCE_SSL follow "is this release published
+  # through a TLS-terminating proxy at all", i.e. ingress.enabled OR
+  # httpRoute.enabled: with either on they render "true" (the proxy terminates
+  # TLS, so Rails must trust the forwarded scheme and may set secure cookies
+  # and HSTS), with both off they render "false" so a plain-HTTP port-forward
+  # can log in at all. Deriving them from ingress.enabled alone was right while
+  # an Ingress was the only way to publish; in Gateway mode ingress.enabled is
+  # false by construction, and the flags would have gone false with TLS still
+  # terminated at the Gateway - insecure cookies and http:// links, with a
+  # green pod and a working UI as the only symptom.
   enabled: true
   clusterIssuer: null
   domain: null
   className: nginx
   # Extra annotations for the Ingress; merged with the cert-manager
   # cluster-issuer annotation the chart always sets.
+  #
+  # THESE HAVE NO COUNTERPART IN GATEWAY MODE. The Gateway API has no
+  # annotation channel for controller behaviour, so anything configured here is
+  # simply gone when httpRoute.enabled is used instead - it is then the
+  # Gateway's business, or that of an implementation-specific policy object
+  # this chart deliberately does not render. Nothing this chart needs lives
+  # here by default; the TLS flags above are environment variables and are
+  # handled in both modes.
   annotations: {}
+
+# Gateway-API alternative to the Ingress above (Gitea #114). Off by default, so
+# an existing release is unaffected; exactly one of ingress.enabled and
+# httpRoute.enabled may be true.
+#
+# The chart renders ONLY an HTTPRoute with parentRefs - no Gateway, no
+# gatewayClassName, no Certificate and no implementation-specific policy
+# object. Class and certificate belong to the Gateway and therefore to the
+# platform, which is what keeps this chart independent of whether the cluster
+# runs nginx-gateway-fabric, Cilium, Envoy Gateway or Istio.
+#
+# The Gateway-API CRDs must be installed in the cluster: the chart does not and
+# cannot detect them (.Capabilities.APIVersions is unreliable at template
+# time), so with httpRoute.enabled: true and no CRDs the INSTALL fails.
+#
+# This value also feeds RAILS_ASSUME_SSL / RAILS_FORCE_SSL - see the note under
+# ingress.enabled above.
+httpRoute:
+  enabled: false
+  # The Gateway(s) this route attaches to - a platform object, usually in
+  # another namespace, which must allow this namespace in its listener's
+  # allowedRoutes. One entry per parent, the fields are the Gateway API's
+  # ParentReference (name, and optionally namespace, sectionName, port, group,
+  # kind), passed through unchanged:
+  #
+  #   parentRefs:
+  #     - name: public
+  #       namespace: gateway
+  #       sectionName: https
+  #
+  # REQUIRED while httpRoute.enabled is true - the render aborts on an empty
+  # list, because a route without a parent is created, is valid and routes
+  # nothing, with no event to say so.
+  parentRefs: []
+  # Empty means [ingress.domain], so the hostname has one source of truth. Set
+  # explicitly only to publish under a different or an additional name - which
+  # is how a migration from the Ingress runs: the HTTPRoute takes a second
+  # hostname while the Ingress keeps ingress.domain.
+  #
+  # BE CAREFUL WITH THIS ONE HERE. A second hostname does not move
+  # WEBAUTHN_RP_ID, which keeps following ingress.domain - and passkeys are
+  # bound to the relying party id, so changing ingress.domain to match
+  # invalidates every registered credential (upstream
+  # docs/hosting/webauthn.md). APP_DOMAIN and WEBAUTHN_ALLOWED_ORIGINS follow
+  # ingress.domain as well.
+  hostnames: []