Symfony version(s) affected: 5.3

Description

Subsequent (n+1) calls to session_start() yield a set-cookie header, even when the session cookie is already present.

This bug is likely due to an underlying issue in PHP itself, however Symfony may wish to implement a workaround. Both of the referenced PHP issues are marked "Won't fix," but dating back to 2005-06. Perhaps it's time to reopen?

How to reproduce

As demonstrated in this proof of concept, open a session, do some business logic (including potentially reading or writing from the cookie) and then save the session. Reopen the session. Print a Response to the browser (optional.) Save the session. The last ::start() call prints a set-cookie header to the browser.

Important note: It's worth noting that this might also yield an unintended extension of the session, beyond what the site owner intended the length to be. Since the settings for the expiration time of the cookie are respected, every page subject to this condition gets refreshed. Since most session regimes intend to set the session cookie once (e.g., on login) this could result in, essentially, unlimited duration sessions if the user visits the affected page at least once before the expiration period.

Possible Solution

This comment proposes a workaround:

A workaround to this issue would be passing the session.use_cookies as false in the $options argument the 2nd time you use session_start(). This off course would only work for users of PHP7.

In Symfony, we could inspect NativeSessionStorage::$closed, and if it's TRUE, set this PHP ini option before (re-)opening.