Re: [Beacon] spec feedback + few suggestions

On Thu, Nov 7, 2013 at 9:57 AM, Ilya Grigorik <igrigorik@google.com> wrote:
> 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.

Actually, unless the Content-Type header is set to anything other than
"application/x-www-form-urlencoded", "multipart/form-data", or
"text/plain", then even POST requests are forbidden cross-origin. :(

Though I agree we should enumerate that more explicitly rather than
mention any CORS headers.

> 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 can live with either solution here, but GET requests are the wrong
thing to use here per the HTTP spec. Per HTTP GET requests are not
supposed to have side effects, and we definitely expect server to have
side effects like logging the beacon.

Also, GET requests aren't supposed to have a request body IIRC.

So you'll incur the wrath of IETF by defaulting to GET :)

> 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.

Agreed.

/ Jonas

Received on Thursday, 7 November 2013 18:57:41 UTC