Hello,
Wessen Instanz, wessen Kinder? Das Session-Cookie verfällt, wenn sein Verfallsdatum abgelaufen ist, nicht früher nicht später. Es kann aber passieren, dass das Cookie eine Session-ID trägt, die auf dem Server nicht mehr existiert.
Wo wird das Cookie denn angelegt? Dort verfällt es auch!
Es muss nicht "kurz eingestellt" werden, denn es steht schon bei "0".
"0" ist kein gültiger Wert für expires. Für max-age kann man "0" angeben, das bedeutet aber, dass das Cookie bereits ungültig ist, weil das Ablaufdatum auf einen implementationsabhängigen Zeitpunkt in der Vergangenheit verweist. Für die meisten Implementation dürfte das dann wohl der Start der UNIX-Epoche sein.
Guckst Du unter "transienter Cookie" im Gegensatz zu "persistenter Cookie". Googlen musst Du bitte mal alleine.
Hier nur ein erster Teffer: http://searchsoa.techtarget.com/definition/transient-cookie
Wenn wir den wegoperierten bidirektionalen Dialog aus TCP in HTTP zumindest halbseitig wieder emulieren wollen
Jetzt habe ich den Faden verloren, reden wir immer noch über Sessions?
Wir reden über Sessions.
Mit TCP kann man eine Session sehr leicht kontrollieren, da beide Partner jederzeit feststellen können, ob der andere noch da ist.
Eine Session stellt die etablierte zustandsorientierte Verbindung zwischen (zwei) (gleichberechtigten) Kommunikationspartern dar. TCP ermöglicht dies. In HTTP ist diese Fähigkeit "wegoperiert"; dort gibt es dedizierte Clients und Server.
Session hat erstmal überhaupt nichts mit Berechtigungen auf hinterliegende Systeme zu tun (Datenhaltung, Programme, ...).
Außerdem könnten andere teilnehmer bereits Hinweise darauf bekommen, dass dieser Teilnehmer schon auf "gelb" steht, noch bevor dessen Session abläuft.
Beschreibe das Szenario, das du hier für problematisch hältst bitte mal etwas genauer. Ich kann dir nicht ganz folgen.
Im Archiv findest Du dazu von mir genügend Beschreibungen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg