I'm currently looking at performance optimization and am considering a way of speeding up cookie based session handling. There are advantages to having a session identifier in place when there is no server-side data referenced by it. I'm trying to work out if it's a good idea to attach an indicator to the session id which shows if there is serverside data. This would avoid the need for attempting to fetch non-existent data in some cases, and could be further extended for other simple cases (e,g, to differentiate between different server-side session data storage backends).
e.g. the first time a user hits a site they get a session id 'abc' and...
Set-Cookie: sessionid=0abc; HttpOnly
When any data is added to the session....
Set-cookie: sessionid=1abc; HttpOnly
Obviously the presence/absence of server-side data will be apparent to an eavesdropper. And there is the potential for the cookie to be tampered with such that it appears to be associated with serverside data - but in this case the worst thing to happen is that it behaves the same way as sessions do currently.
I'm also mindful, that in the EU we must now ask users for consent before dropping any non-critical cookies.
Further, I'm not proposing to use 3 letter session identifiers! Apart from a small stub, the remainder of the session id would continue to follow usual practices of being essentially random data. I'm assuming that there's no gain to be made by regnerating this at the point where the stub changes.
But can anyone see an issue I don't?