by David LeMieux
In the web advertising world everyone wants to know when and where an ad is being served. There are a number of ways to track this, but a common practice by many third-party ad tracking services is to give the ad creator or publisher a url to a transparent 1x1 gif that serves as a homing beacon of sorts. It loads in the background, you cannot see it, and it sends data to the server in the form of an HTTP request.
This method takes a URL to request and then data to be added to the request body (always a POST request). The idea is that this request is not canceled by user navigation and is more-or-less guaranteed to be made. This sounds delightful, from an ad or metrics perspective, but there are some caveats.
First, the data is sent as a POST, but not as form data. Instead it is included as part of the request body. This isn't a difficulty, but it means your server side code has to know how to parse this data and use it. There can be complication with this depending on what technology you are using. For example, certain Java servlet filters might try and access the body, but it can only be accessed once since it is an input stream.
Second, in case you considered using this with third-party tracking pixels, not every third-party tracker allows POST requests. This negates any usefulness and the feature almost entirely.
Finally, some browsers have a data limit of how much data, per page view, can be sent by the sendBeacon API. In my testing I have noticed that this only includes actual POST body data, so you can still send quite a lot on the query string if you want.
navigator.sendBeacon is not yet supported in every browser, but I think it will be a useful browser feature when it is, as long as one understands the limitations - which are likely to change or be different in each browser.