- From: Martin Atkins <mart@degeneration.co.uk>
- Date: Wed, 10 Feb 2010 00:44:20 -0800
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.
Received on Wednesday, 10 February 2010 00:44:20 UTC