- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 11 Feb 2014 00:50:36 -0800
- 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