W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2014

[Beacon] Data: Optional? Nullable?

From: Richard Barnes <rbarnes@mozilla.com>
Date: Mon, 10 Feb 2014 18:24:09 -0500
Message-ID: <52F95F99.4060503@mozilla.com>
To: public-web-perf@w3.org
Hey all,

I've been working on implementing Beacon in Firefox, and have had some 
internal discussion with folks about the proper type for the "data" 
parameter.

tl;dr: Data needs to be nullable and/or optional to avoid weird behavior.

The current ED has the following:

partial interface Navigator {
     boolean sendBeacon(DOMString url,
     (ArrayBufferView or Blob or DOMString or FormData) data);
};

That leads to behaviour that seems broken.  Since "DOMString" is 
included in the list of allowed types, if the JS passes in null or 
undefined, it gets converted to the string "null" or "undefined".  From 
what I hear from WebIDL gurus, that is not just a Firefox quirk, it's 
the specified behavior for WebIDL.  This is weird not just because of 
the string conversion, but also because the behavior of 
sendBeacon(target, null) (send "null" as text/plain) differs from 
sendBeaecon(target) (error).

So we've got two questions here:
1. How should sendBeacon behave when data is null?
2. How should sendBeacon behave when data is not provided?

In each case, it seems like the right answer is either to throw or send 
a query with no body.  And it seems to me that the answer to both should 
be the same (for developer sanity).

If we're going to throw, then we need to revert to what's in the TR:
-- Make data nullable:
    (ArrayBufferView or ...)? data
-- Require that the UA throw on null data

If we're going to send an empty request, then we probably shouldn't use 
POST.  So we would want to:
-- Make data nullable and optional and default null:
    optional (ArrayBufferView or ...)? data = null
-- Require that the UA use the GET method if data is null

My personal preference would be to send empty data, since that seems 
useful and consistent with the semantics one might expect.  But I care 
more about having a consistent behavior here than what the behavior is.

Please CC my address on replies, since I am not subscribed to this list.

Thanks,
--Richard
Received on Tuesday, 11 February 2014 08:06:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:38 UTC