This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On Thu, 31 Oct 2013, Kyle Simpson wrote: > > Session cookies are preserved at the browser-level, which means they are > kept around for the lifetime of the browser instance. sessionStorage, > OTOH, is kept only for the lifetime of the tab. In many respects, this > makes sessionStorage more desirable for session-based tracking. > > 2. As a consequence of #1, the most pertinent difference is > sessionStorage based session-IDs being attached to an individual tab > rather than the browser. This means if I open up two tabs to the same > site, and I use session cookies, then both tabs share the same session > (can be useful or can be very annoying). > > But with a sessionStorage based approach, the two tabs have two entirely > separate sessions and operate independently. They can share storage > through localStorage, if so desired, and even communicate with > StorageEvents. But they can be separate if they want by relying on > sessionStorage. > > In particular, #2 is a big win (IMO) for session-based architecture (as > well as UX) and I often now design my systems with this particular > behavior intentionally relied upon. Kyle's proposed solution (if I understood it right) would be to include some data from sessionStorage in the HTTP requests, basically a sessionStorage-mediated cookie header.
I explain my proposal in detail here: https://gist.github.com/getify/7240515 and here: http://blog.getify.com/tale-of-two-ends/#proposal-hope TL;DR A server response header registers the name (and optionally value) of a session-ID to be stored in the browser's sessionStorage. On subsequent requests (in the session of course!), it checks the sessionStorage for that key and if present, includes its value in a request header, *similar* to how session cookies get included. The key difference is that sessionStorage backed session-IDs live only for the tab lifetime, whereas session cookies span the whole browser instance lifetime. The former is a more desirable behavior in many use-cases that I'm solving for. But the big blocker to not using sessionStorage for tracking session-IDs is that the initial page request (from URL nav, link clicking, history, bookmark, etc) to the server does not check and include such information, so the server cannot respond with a session-aware response. It must wait then for the page to make another Ajax request where it manually extracts and includes the session-ID. This leads to poorer UX.
What about Session expering,?
This is probably something better done at the ServiceWorker / Fetch level, rather than supporting it directly in the platform.