With the current implementation of session handling, gorouter sets a VCAP_ID cookie if a session cookie, by default JSESSIONID, is present in the application response. Some cookie parameters, such as the Expiry timestamp and the 'Partitioned' flag, are copied from the session cookie to VCAP_ID. However, the Max-Age attribute is only copied if its value in the session cookie is 0 or negative. This is an inconsistent behaviour, as the Expiry attribute is always copied, and Max-Age takes precedence over Expiry.
This can lead to unexpected and undesired behaviour: When providing a positive Max-Age value for the session cookie, it can expire once Max-Age has been reached, but the VCAP_ID cookie is still valid. In the next request, gorouter will not consider it, as the expired session cookie is missing.
However, in the case the orphan VCAP_ID cookie is unpartitioned, and the next session cookie retrieved by another instance is partitioned, two VCAP_ID cookies will co-exist (one partitioned and one unpartitioned). The session cookie matches to the instance of the partitioned VCAP_ID cookie, which can differ from the unpartitioned and still valid VCAP_ID cookie.
By default, cookies with the same path are sorted by their creation-times. Hence, the unpartitioned VCAP_ID cookie, along the partitioned session cookie, are effective. As the session cookie doesn't match to the instance in the unpartitioned VCAP_ID cookie, the instance will cause another authentication flow.
We cannot rule our that other scenarios might occur when the Max-Age attribute is not copied to the VCAP_ID cookie.
The conditional Max-Age attribute has been introduced 10 years ago with a bugfix resolving an issue that prevented reestablishing a sticky session.
Are there other reasons why we would want to keep the VCAP_ID cookie after the session cookie has expired?
Desired behavior
The Max-Age cookie attribute should unconditionally be copied from the session cookie to the VCAP_ID cookie.
Current behavior
With the current implementation of session handling, gorouter sets a
VCAP_IDcookie if a session cookie, by defaultJSESSIONID, is present in the application response. Some cookie parameters, such as theExpirytimestamp and the 'Partitioned' flag, are copied from the session cookie toVCAP_ID. However, theMax-Ageattribute is only copied if its value in the session cookie is 0 or negative. This is an inconsistent behaviour, as theExpiryattribute is always copied, andMax-Agetakes precedence overExpiry.This can lead to unexpected and undesired behaviour: When providing a positive
Max-Agevalue for the session cookie, it can expire onceMax-Agehas been reached, but theVCAP_IDcookie is still valid. In the next request,gorouterwill not consider it, as the expired session cookie is missing.However, in the case the orphan
VCAP_IDcookie is unpartitioned, and the next session cookie retrieved by another instance is partitioned, twoVCAP_IDcookies will co-exist (one partitioned and one unpartitioned). The session cookie matches to the instance of the partitionedVCAP_IDcookie, which can differ from the unpartitioned and still validVCAP_IDcookie.By default, cookies with the same path are sorted by their creation-times. Hence, the unpartitioned
VCAP_IDcookie, along the partitioned session cookie, are effective. As the session cookie doesn't match to the instance in the unpartitionedVCAP_IDcookie, the instance will cause another authentication flow.We cannot rule our that other scenarios might occur when the
Max-Ageattribute is not copied to theVCAP_IDcookie.The conditional
Max-Ageattribute has been introduced 10 years ago with a bugfix resolving an issue that prevented reestablishing a sticky session.Are there other reasons why we would want to keep the
VCAP_IDcookie after the session cookie has expired?Desired behavior
The
Max-Agecookie attribute should unconditionally be copied from the session cookie to theVCAP_IDcookie.Affected Version
current main