[whatwg] When closing the browser

Ian Hickson wrote on 6/4/2009 7:02 PM: 
> On Mon, 27 Apr 2009, Tab Atkins Jr. wrote:
>> On Mon, Apr 27, 2009 at 1:24 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> One option would be to have an attribute, say <body logout="">, which
>>> causes the user agent to ping the site when the window is closed and there
>>> are no other windows open to the same origin.
>>> Of course this would break if the other window in question was open to a
>>> different page that didn't have the logout="" attribute..
>>> Maybe it should be invoked if there are no other pages open that have the
>>> same logout="" attribute?
>>> This has the advantage of not depending on JavaScript, and not affecting
>>> the browser's performance (no waiting for sync XHR, etc).
>>> It would work somewhat like PING does today, though probably using POST.
>> As an author, I'd definitely use it.  I'd want the second option (ping 
>> when you close the last window with a given logout attribute), as that 
>> would allow me to define 'domains' within the same origin that track 
>> logins separately.
>> It would be easy to code against the lack of this (just do an occasional 
>> cleanup of sessions that have aged too much, which you'd have to do 
>> anyway in case of nonstandard browser exits), but would allow better, 
>> more reliable security for users with browsers that implement it.
>> Trying to handle this through javascript onunload is nontrivial 
>> currently, but @logout would make it both trivial and dependable.
> On Mon, 27 Apr 2009, Jo?o Eiras wrote:
>> What if there is a loss of connectivity or the user agent crashes ? 
>> Relying on user agent telling when documents are unloaded has never been 
>> reliable nor will ever be. So, websites do timeouts and will continue to 
>> do so because those are needed.
>> This is really about making the whole logout process more friendly for 
>> the web developer though. I thought of exporting a service, using a 
>> special element or something, which the user agent could call when if 
>> unloads all documents related to that origin or a special token in that 
>> element. Like <logout specialtoken="123abcsessionid" content="/logout">
>> The user agent would do a GET request of /logout when it no longer had 
>> documents loaded on windows with a logout tag with that specific 
>> specialtoken value. specialtoken (or whaever you'd like to call it) 
>> could be optional and in that case the user agent could rely on origin.
>> This way, the server would not need to count the number of loaded 
>> documents.
> On Mon, 27 Apr 2009, Philipp Kempgen wrote:
>> Maybe <link rel="logout" href="..."> is more suitable?
>> Server-side applications should probably implement that in a way such 
>> that just one session (identified by a session cookie or whatever) gets 
>> logged out -- in contrast to all sessions of a user. The user might be 
>> logged in using 2 different browsers and might want to log out in one 
>> browser but keep the session active in the second one.
>> And I'd probably want a same domain policy for the logout ping be 
>> implemented in the browser.
> On Tue, 28 Apr 2009, Bil Corry wrote:
>> I like the idea -- thinking out loud here, rather than invoking it when 
>> all pages having the same logout="" attribute are closed, can it instead 
>> use some other grouping identifier?  That would allow a developer to 
>> pass back unique information from each page via the URI.  And I like 
>> POST instead of GET.  A same-origin restriction would be good too.  
>> Would the browser accept a response from the logout?  I'm thinking that 
>> could be used to immediate end the cookie(s).
> I like Philipp's idea of making this a new "rel" value. I encourage people 
> who are interested in this idea to add it to the WHATWG RelExtensions 
> wiki, write a spec for it (you can put it on a page on that wiki if you 
> like) and then see if browser vendors are interested in supporting this 
> feature.

I've added a quick first draft to the wiki:


I don't know the correct vernacular for these types of documents, so if it should be URL instead of URI, etc, then feel free to edit the wiki directly.

- Bil

Received on Saturday, 20 June 2009 12:51:38 UTC