- From: Richard Barnes <rbarnes@mozilla.com>
- Date: Mon, 10 Feb 2014 18:24:09 -0500
- 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