I think CORS might still be needed as the data is not necessarily posted to the 
origin server. The name unloadRequest might be a bit misleading as this 
functionality might be used in a non unload situation as well. I also agree on 
the script-only capability.

// Alois

From: Dave Methvin <dave.meth...@gmail.com<mailto:dave.meth...@gmail.com>>
Date: Wednesday, February 13, 2013 7:18 PM
To: "Tab Atkins Jr." <jackalm...@gmail.com<mailto:jackalm...@gmail.com>>
Cc: Jatinder Mann <jm...@microsoft.com<mailto:jm...@microsoft.com>>, 
<public-webapps@w3.org<mailto:public-webapps@w3.org>>, Alois Reitbauer 
Subject: Re: Beacon API

On Wed, Feb 13, 2013 at 11:45 AM, Tab Atkins Jr.
I started a thread last year in WHATWG about this subject, though from
a slightly different angle:

A new simple API sounds like the best solution. Adding a sufficiently limited 
beacon into XHR would seem to involve a lot of special cases, since you don't 
want the response, callbacks, CORS, etc. but the requests themselves would need 
to stay around after the page is done.

It might be handy to have a method property to specify get/post and I'd prefer 
a name like unloadRequest since it's making a request and not setting a 
handler. Finally, is script-only capability sufficient or does it make sense to 
also have some form of markup specifying a link to be visited when the page 
unloads? </bikeshed>

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a 
company registered in Vienna whose registered office is at 1120 Wien, Austria, 
Am Euro Platz 2 / Geb?ude G.

Reply via email to