Fix Cookie Attributes on Sticky Session Refresh by hoffmaen · Pull Request #534 · cloudfoundry/routing-release

hoffmaen · 2026-03-04T12:31:39Z

Read the Contributing document.

Summary

When an application sets a partitioned JSESSIONID cookie, Gorouter sets a matching partitioned __VCAP_ID__ cookie. However, when a subsequent request references a stale application instance and the new instance does not respond with a new JSESSIONID cookie, Gorouter had no way of knowing whether the client's existing __VCAP_ID__ was partitioned — since cookie attributes are never transmitted from the client to the server. As a result, Gorouter always created a new unpartitioned __VCAP_ID__ cookie in this case, leaving the client with both an orphaned partitioned and a new unpartitioned __VCAP_ID__ cookie. This broke sticky session routing for partitioned cookies, as browsers such as Chrome would prefer the stale partitioned cookie over the new unpartitioned one.

This Pull Request introduces a new metadata cookie, __VCAP_ID_META__, which Gorouter sets alongside __VCAP_ID__ whenever it creates a sticky session (i.e. the application responds with a matching session cookie such as JSESSIONID). The metadata cookie encodes all relevant __VCAP_ID__ attributes — Partitioned, Secure, SameSite, and Expiry — as a compact &-separated key=value string (e.g. expiry=1748001600&secure=1&samesite=none&partitioned=1). In the stale instance scenario, when the new instance does not set a new JSESSIONID cookie, Gorouter reads __VCAP_ID_META__ from the incoming request and reconstructs the refreshed __VCAP_ID__ with the original attributes preserved.

The expiry lifetime is stored as an absolute Unix timestamp rather than a relative Max-Age value. This ensures that a stale instance refresh does not silently extend the user's session: the refreshed __VCAP_ID__ receives an Expires header set to the original absolute point in time, so the remaining session lifetime is preserved exactly.

__VCAP_ID_META__ is issued with the same attributes (Secure, SameSite, Partitioned, Expiry) as __VCAP_ID__ itself, so the two cookies co-expire and share the same security constraints.

Closes #529 (Problem 1).

Backward Compatibility

Breaking Change? No
All clients that use sticky sessions will now additionally receive the __VCAP_ID_META__ cookie alongside __VCAP_ID__. This is a net improvement: without it, sticky session routing for partitioned cookies in the stale instance scenario was already broken, and attributes such as Secure and SameSite were not preserved on refresh for any client. Clients that do not use sticky sessions are entirely unaffected.

…router when the JSESSIONID and __VCAP_ID__ cookies are set with the Partitioned attribute.

maxmoehl

I have some concerns when it comes to adding a second cookie:

Yet another cookie which has to be correlated, can be duplicated, etc. Based on your description the meta cookie encodes its own attributes, that would at least allow gorouter to clear it. But if you suddenly have two of those but one regular VCAP cookie it gets weird again.¹
This is a bit more vague but there might be environments in which cookies are tracked to some extent and a new cookie could cause confusion / issues.

I'd prefer if we could evolve the format of the __VCAP_ID__ cookie instead:

Add a feature flag for vcap_id_cookie_v2 which takes the values disabled (default), accept, and emit.
On disabled nothing changes, gorouter behaves as before.
On accept gorouter tries to detect the new format and parse it, falling back to the current format if that fails.
On emit it starts setting the VCAP_ID cookie according to the new format.
Add version=2 and value=$value to the cookie value.

All names are for illustration purposes only.

Yes, I know, you can then just clear both. It still adds complexity. ↩

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

hoffmaen · 2026-03-12T08:28:16Z

I have some concerns when it comes to adding a second cookie:

1. Yet another cookie which has to be correlated, can be duplicated, etc. Based on your description the meta cookie encodes its own attributes, that would at least allow gorouter to clear it. But if you suddenly have two of those but one regular VCAP cookie it gets weird again.[1](#user-content-fn-1-7ae6470452031de3247e0828ab074f13)

2. This is a bit more vague but there might be environments in which cookies are tracked to some extent and a new cookie could cause confusion / issues.

I'd prefer if we could evolve the format of the __VCAP_ID__ cookie instead:

* Add a feature flag for `vcap_id_cookie_v2` which takes the values `disabled` (default), `accept`, and `emit`.

* On `disabled` nothing changes, gorouter behaves as before.

* On `accept` gorouter tries to detect the new format and parse it, falling back to the current format if that fails.

* On `emit` it starts setting the VCAP_ID cookie according to the new format.

* Add `version=2` and `value=$value` to the cookie value.

All names are for illustration purposes only.

Footnotes

1. Yes, I know, you can then just clear both. It still adds complexity. [↩](#user-content-fnref-1-7ae6470452031de3247e0828ab074f13)

I appreciate the idea, but I see a few drawbacks here:

Introducing a feature-flag, and then releasing the features in two phases means an additional delay to the rollout of the fix.
We do not know if anyone relies on the format of the __VCAP_ID__ cookie as it is - it only stores the App Instance GUID. Changing the format is a breaking change.
I don't like introducing a feature flag for a thing that is not a feature - to me, this is a bug fix.

a18e · 2026-03-23T11:57:17Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

+	logger *slog.Logger,
 ) {
+	sessionCookie, vcapCookie := getSessionCookiesFromResponse(response, stickySessionCookieNames)
+	if vcapCookie != nil {


A comment to explain the early return like "Sticky Session already established previously, nothing more to do" would be nice.

a18e · 2026-03-23T12:00:17Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

 }

+// stickySessionCase identifies which of the three mutually exclusive sticky-session paths applies to the current request/response pair.
+type stickySessionCase int


How about

Suggested change

type stickySessionCase int

type stickySessionScenario int

Also: With the new simplified structure I'm not sure if we need it at all...

a18e · 2026-03-23T12:01:38Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

+	// stickySessionAuthNegotiate: first request of a Kerberos/SPNEGO handshake; fixed cookie defaults apply.
+	stickySessionAuthNegotiate stickySessionCase = iota
+	// sessionCookieInAppResponse: application set a JSESSIONID in the response; attributes are copied from it.
+	sessionCookieInAppResponse


Maybe this (or sth similar) makes the scenario more clear?

Suggested change

sessionCookieInAppResponse

newStickySessionRequested

a18e · 2026-03-23T12:12:41Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

+		vcapCookie.MaxAge = sessionCookie.MaxAge
+		vcapCookie.Expires = sessionCookie.Expires
+		createMetaCookie = true
+	default: // case stickySessionStaleInstance


I know why we did this (to avoid the "stickySessionStaleInstance is always true" thing right?).
But a bit more information for others might be helpful.

a18e · 2026-03-23T12:15:25Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

-	sameSite := http.SameSite(0)
-	expiry := time.Time{}
-	partitioned := false
+	// Create sticky session with default cookie attributes


Suggested change

// Create sticky session with default cookie attributes

// Create VCAP_ID cookie with default cookie attributes

a18e · 2026-03-23T12:18:41Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

-				expiry = v.Expires
-				partitioned = v.Partitioned
+	addCookieToResponse(response, vcapCookie)
+	if createMetaCookie {


Hey, since we're only setting this in the case sessionCookieInAppResponse, why not set it there directly and save ourselves the var createMetaCookie?

Edit: Because we would have to specify if secureCookies {vcapCookie.Secure = true} twice
Edit2: But we could just doo ....Secure = vcapCookie.Secure || secureCookies

Setting attributes in one place, and adding cookies in another keeps the code structure clean. I think this is a legitimate reason to keep the few extra lines.

a18e · 2026-03-23T12:22:27Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go


-				break
+// getSessionCookiesFromResponse returns the session cookie and __VCAP_ID__ cookie, when they exist in the response
+func getSessionCookiesFromResponse(response *http.Response, stickySessionCookieNames config.StringSet) (sessionCookie *http.Cookie , vcapIdCookie *http.Cookie) {


Suggested change

func getSessionCookiesFromResponse(response *http.Response, stickySessionCookieNames config.StringSet) (sessionCookie *http.Cookie , vcapIdCookie *http.Cookie) {

func getSessionCookies(response *http.Response, stickySessionCookieNames config.StringSet) (sessionCookie *http.Cookie , vcapIdCookie *http.Cookie) {

a18e · 2026-03-23T12:30:45Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

-		if secureCookies {
-			secure = true
+// parseVcapMeta deserializes the __VCAP_ID_META__ cookie value.
+func parseVcapMeta(value string) (*vcapAttributes, error) {


Could we use some other kind of serialization that doesn't involve manual rules?

Option A: Intermediate JSON struct — keep vcapAttributes as-is, marshal/unmarshal via a separate vcapAttributesJSON with string fields and JSON tags. Simple, no custom marshaler needed.
Option B: JSON tags + custom marshaler on vcapAttributes — add MarshalJSON/UnmarshalJSON to vcapAttributes. More self-contained but more boilerplate.

Would probably be less performant though

binary serialization (e.g. encoding/gob, protobuf, msgpack) would be faster and more compact than JSON, but you'd still be slower than the current url.Values approach for a payload this small.

As discussed: We'll leave it as is, but will consider adding valueless params for booleans (e.g. if params.Get("secure") { metaAttributesFromCookie.secure = true }

a18e · 2026-03-23T13:56:12Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

-		for _, v := range response.Cookies() {
-			if _, ok := stickySessionCookieNames[v.Name]; ok {
-				shouldSetVCAPID = true
+	if secureCookies {


Comment: point to global config value and that it overrides the per-cookie prefernce

a18e · 2026-03-23T13:59:03Z

src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go

+			return vcapMetaAttributes
 		}
 	}
+	logger.Info("vcap-id-meta-cookie-not-found")


Add comment that we expect to see these logs during the migration to the new cookie handling, but not after?

hoffmaen added 3 commits March 4, 2026 09:54

Implement additional __VCAP_ID_PARTITION__ cookie, which is set by Go…

73177a0

…router when the JSESSIONID and __VCAP_ID__ cookies are set with the Partitioned attribute.

Refactor and add tests for sticky session cookies

1203785

Update session affinity docs

ef72074

hoffmaen mentioned this pull request Mar 4, 2026

Do not update VCAP_ID cookie without JSESSIONID cookie #531

Closed

1 task

cf-foundation-community-automation bot added this to Application Runtime Platform Working Group Mar 4, 2026

cf-foundation-community-automation bot moved this to Inbox in Application Runtime Platform Working Group Mar 4, 2026

hoffmaen changed the title ~~Fix Session Affinity Recovery via new Gorouter sticky session cookie~~ Fix Partitioned Cookies Session Affinity Recovery Mar 4, 2026

Introduce generic VCAP_ID metadata cookie

9919b15

hoffmaen changed the title ~~Fix Partitioned Cookies Session Affinity Recovery~~ Fix Cookie Attributes on Sticky Session Refresh Mar 9, 2026

hoffmaen marked this pull request as ready for review March 9, 2026 15:44

hoffmaen requested a review from a team as a code owner March 9, 2026 15:44

hoffmaen mentioned this pull request Mar 9, 2026

Fix Session Affinity With Partitioned Session Cookies #529

Open

maxmoehl requested changes Mar 10, 2026

View reviewed changes

hoffmaen added 2 commits March 10, 2026 11:14

Address review findings

9935e70

(Re)Store Max-Age and Expires attributes as present in original cookie

191472e

hoffmaen force-pushed the partition-metadata-cookie branch from 1d3cfb0 to 191472e Compare March 10, 2026 13:06

Fixes and refactorings

0a0596b

a18e self-assigned this Mar 11, 2026

hoffmaen added 7 commits March 13, 2026 11:15

Refactor tests

d86a86b

Update docs and images

6649b18

Refactor sticky session cases

9cb9762

Fix stale session + Auth negotiation case

2a64948

Refactor sticky session

015d377

Continue refactoring

d10fed8

Continue refactoring

36866d2

hoffmaen mentioned this pull request Mar 19, 2026

Implement Hash-Based Routing #519

Open

1 task

hoffmaen added 3 commits March 19, 2026 16:40

Continue refactoring

943b384

Add logging tests

c8ec6fe

Add more logging and tests for parsing errors

30e3c29

Minor changes

320bdc2

a18e reviewed Mar 23, 2026

View reviewed changes

Address second round of reviews

f98f2af

hoffmaen force-pushed the partition-metadata-cookie branch from 774d7a0 to f98f2af Compare March 23, 2026 15:34

Address second round of reviews, pt 2

a908e5f

	// Create sticky session with default cookie attributes
	// Create VCAP_ID cookie with default cookie attributes

	func getSessionCookiesFromResponse(response http.Response, stickySessionCookieNames config.StringSet) (sessionCookie http.Cookie , vcapIdCookie *http.Cookie) {
	func getSessionCookies(response http.Response, stickySessionCookieNames config.StringSet) (sessionCookie http.Cookie , vcapIdCookie *http.Cookie) {

Conversation

hoffmaen commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Backward Compatibility

Uh oh!

maxmoehl left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hoffmaen commented Mar 12, 2026

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

hoffmaen commented Mar 4, 2026 •

edited

Loading

maxmoehl left a comment •

edited

Loading