From 9c358b6247fe68ee737f60d56d9f710866586580 Mon Sep 17 00:00:00 2001 From: salonichf5 <146118978+salonichf5@users.noreply.github.com> Date: Tue, 18 Nov 2025 18:18:06 -0700 Subject: [PATCH 1/2] update session persistence design --- docs/proposals/session-persistence.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/proposals/session-persistence.md b/docs/proposals/session-persistence.md index 7484cc43c4..dfa81a1b0f 100644 --- a/docs/proposals/session-persistence.md +++ b/docs/proposals/session-persistence.md @@ -150,9 +150,9 @@ To determine the cookie `path` for HTTPRoutes, we handle the simple case where t | Path Value | Path Match Type | Cookie `Path` Value | Cookie Match Expectations | |-------------------------------------|-----------------|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------| -| `/hello-exact` | Exact | `/hello-exact` | Cookie header is sent for `/hello-exact` path only. | -| `/hello-prefix` | Prefix | `/hello-prefix` | Cookie header is sent for `/hello-prefix` and any subpath starting with `/hello-prefix` (e.g. `/hello-prefix/foo`). | -| `/hello-regex/[a-zA-Z0-9_-]+$` | Regex | `/hello-regex` | Cookie header is sent for any request whose path starts with `/hello-regex` and matches the regex in the location block (e.g. `/hello-regex/a`, `/hello-regex/abc123`). The regex still determines which requests match the route on the server side. | +| `/hello-exact` | Exact | `/hello-exact` | Cookie header is sent for `/hello-exact` path only. | +| `/hello-prefix` | Prefix | `/hello-prefix` | Cookie header is sent for `/hello-prefix` and any subpath starting with `/hello-prefix` (e.g. `/hello-prefix/foo`). | +| `/hello-regex/[a-zA-Z0-9_-]+$` | Regex | `/hello-regex` | No `path` attribute is set for pathType `RegularExpression` | When there are multiple path matches that share the same sessionPersistence configuration, we derive a single cookie path by computing the longest common prefix that ends on a path-segment boundary `/`. If no non-empty common prefix on a segment boundary exists, we fall back to `/` which is allowing all paths. @@ -177,6 +177,7 @@ The main security concern is how far session cookies reach. This design keeps co - If an implementation routes through Service IPs, any Gateway-level session persistence must be rejected when Service-level session affinity is enabled. In our case, the data plane routes directly to pod IPs, so Service affinity does not interfere with session persistence between the gateway and backends. - For traffic-splitting configurations, if cookie-based session persistence is enabled, sessions must remain pinned consistently across the split backends. +- In NGINX Gateway Fabric, each valid backendRef maps to a single upstream that owns the session persistence settings. When multiple rules share the same backendRef, their session persistence configs must match otherwise that `backendRef` is treated as invalid for session persistence and no `sticky cookie` is configured on its upstream. ### Future work From 142008d8ec2bf932a64949776099bfc02d38ad9d Mon Sep 17 00:00:00 2001 From: salonichf5 <146118978+salonichf5@users.noreply.github.com> Date: Wed, 19 Nov 2025 12:10:38 -0700 Subject: [PATCH 2/2] update the design based on discussions --- docs/proposals/session-persistence.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/proposals/session-persistence.md b/docs/proposals/session-persistence.md index dfa81a1b0f..f186c758e6 100644 --- a/docs/proposals/session-persistence.md +++ b/docs/proposals/session-persistence.md @@ -177,7 +177,7 @@ The main security concern is how far session cookies reach. This design keeps co - If an implementation routes through Service IPs, any Gateway-level session persistence must be rejected when Service-level session affinity is enabled. In our case, the data plane routes directly to pod IPs, so Service affinity does not interfere with session persistence between the gateway and backends. - For traffic-splitting configurations, if cookie-based session persistence is enabled, sessions must remain pinned consistently across the split backends. -- In NGINX Gateway Fabric, each valid backendRef maps to a single upstream that owns the session persistence settings. When multiple rules share the same backendRef, their session persistence configs must match otherwise that `backendRef` is treated as invalid for session persistence and no `sticky cookie` is configured on its upstream. +- When multiple HTTPRoute rules reference the same backend but define different (or no) sessionPersistence settings, session persistence is treated as rule-scoped rather than backend-scoped. For each unique combination of backendRef and session persistence configuration, the controller generates a dedicated NGINX upstream and wires that rule’s internal location to it. ### Future work