Re: [Beacon] Data: Optional? Nullable?

On Mon, Feb 10, 2014 at 3:33 PM, Richard Barnes <rbarnes@mozilla.com> wrote:
> 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".

This is quite normal JS behavior, so I wouldn't call it "broken".

However I would expect authors to be surprised that you have to send a
body. Including all the data that the server cares about in the URL
seems like a quite normal thing to do so I think it's something that
we should allow.

So I think we should make the argument nullable, let null mean "send
no data" (and thus no Content-Type header), and make the argument
optional and default to null.

> 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 both cases I think we should send no request body, but otherwise
use normal behavior.

> If we're going to send an empty request, then we probably shouldn't use
> POST.

Not having a request body for POST requests seems fully compliant with
http 1.1. So I don't think we need to make any special exceptions
here.

/ Jonas

Received on Tuesday, 11 February 2014 08:51:38 UTC