[whatwg] Window id - a proposal to leverage session usage in web application

Martin Atkins mart at degeneration.co.uk
Wed Feb 10 00:44:20 PST 2010


Sebastian Hennebrueder wrote:
> 
> thank you for the feedback. I hope that I see your point correctly. You 
> are right, that for JavaScript based applications this can easily be 
> solved with a sessionStorage. All technologies around GoogleWebToolkit, 
> Dojo, Echo etc which hold the state in the client and make use of a 
> stateless server side application can use the session storage to 
> distinguish browser windows.
> 
> But there are a lot of web technologies which hold the state on the 
> server using the browser session. Technologies like Ruby on Rails, 
> JavaServerFaces, Wicket, Struts, Tapestry to name a couple of them. 
> Those technologies can not make a simple use of the session storage. 
> They are only aware of the browser session which is a common space of 
> all browser windows. The windows id let them split the session in a per 
> browser window scope.
> 
> Originally, when playing with the window id concept, I simulated a 
> window id by storing it in a session storage and adding it with the help 
> of JavaScript as parameter to all links and as hidden field to all 
> forms. It works to some extend but it pollutes the URL and is likely to 
> cause problems with bookmarking and there is a use case where it fails. 
> If you open a link in a new windows. In that case the first request is 
> sending the wrong windows id.
> 
> 

The server-side session management you describe is usually implemented 
via cookies, which as you note are scoped to a particular site and do 
not consider a particular window.

Cookies and sessionStorage are conceptually similar in that both of them 
are mechanisms to allow a site to store data on the client. 
sessionStorage sets the scope of this data to be a (site, window) tuple 
rather than just site.

So it seems like your use-case could also be addressed by providing an 
interface to sessionStorage that uses HTTP headers, allowing the server 
to use sessionStorage in the same way that cookies are used, without 
requiring client-side script and thus requiring the data to be set via 
an HTML page.

To emulate the server-side session mechanisms you describe, you'd simply 
use a single sessionStorage value containing a session id which gets set 
in response to any request that does not provide it.





More information about the whatwg mailing list