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

Re: [Beacon] Data: Optional? Nullable?

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 11 Feb 2014 00:50:36 -0800
Message-ID: <CA+c2ei_JPGHSpUTm1K+Ddbmxjzw_AmrfVa7WAj_kyZBN1hKhgw@mail.gmail.com>
To: Richard Barnes <rbarnes@mozilla.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
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

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