Meine Herren!
Ja, ok. Machen wir das doch.
Das "Session-Cookie" hat ein Ablaufdatum, das dazu führt, dass es verfällt, wenn die dazugehörige Instanz (und ihre Kinder) verfallen.
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.
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.
Die Lebensdauer der Sessiondatei sollte auch nicht die Lebensdauer der Session steuern. Sie begrenzt sie allerdings, ist also bitteschön größer, als die Session.
Ich habe nie von der Lebensdauer der Session-Datei gesprochen. Da hast du mich auch hier schon missverstanden. Ich habe versucht die zeitliche Abfolge zu erklären, wann eine Sitzung unerreichbar wird, weil die Session-ID nicht mehr existiert, wann die Session-Daten zu Müll verkommen und wann sie endgültig gelöscht werden.
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?
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.
“All right, then, I'll go to hell.” – Huck Finn