Re: [Beacon] spec feedback + few suggestions

Great stuff, thanks Jatinder! A couple of notes:

--

> (under 4.2) Throwing the SyntaxError exception for a unsupported method
of transmission may not always be possible, as the User Agent may not yet
have received the Access-Control-Allow-Methods CORS header.

Isn't this redundant? If we limit cross-origin requests to GET/POST
then Access-Control-Allow-Methods should not be required to begin with.

--

Given that most existing analytics beacons rely on <img> and XHRs GETs,
would it make more sense to default to GET?

navigator.sendBeacon("/log?var=a", "GET", null); // "GET" as default +
analyticsData is optional.
navigator.sendBeacon("/log?var=a"); // equivalent to above?
navigator.sendBeacon("/log", "POST", analyticsData);

--

I think we should require sendBeacon to automatically append cookies (aka
default to "withCredentials = true" in XHR speak). Most existing <img>
beacons rely on cookies in addition to query params.

--

Should there be a note that UA will ignore any and all response bodies?
Perhaps recommend returning 204 from server.

--

Working with GA team to get the beacon size data. They also suggested some
other good feedback.. stay tuned.

ig





On Wed, Nov 6, 2013 at 10:25 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Nov 6, 2013 4:11 PM, "Jatinder Mann" <jmann@microsoft.com> wrote:
> >
> > Based on feedback on this thread, I’ve updated the latest editor’s draft
>
> Looks great. The only thing I would add is that if we want to add ability
> to set headers in the future, we might want to make the last argument a
> dictionary instead of a string.
>
> Also, POST might be a better default given that the request body is not
> optional, and GET requests doesn't have a request body per http 1.1.
>
> / Jonas
>

Received on Thursday, 7 November 2013 17:59:05 UTC