RE: [Beacon] spec feedback + few suggestions

One of the primary goals of this interface is to send data without slowing the page down (e.g., not holding up the unload of the page). If we don't require or recommend a limit, this API could be used to send large amounts of background data and instead cause a performance regression (e.g., more power usage).

We could allow UAs to change the limits, but having a well known limit may be easier than having to query to figure out the limits.

From: Chase Douglas [mailto:chase@newrelic.com]
Sent: Wednesday, October 30, 2013 12:05 PM
To: Jatinder Mann
Cc: Ilya Grigorik; public-web-perf; Jonas Sicking
Subject: Re: [Beacon] spec feedback + few suggestions

On Wed, Oct 30, 2013 at 11:36 AM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:
> Beacon API should limit size of send payload to <TBD> KB
I agree that we should add a limit. I've heard feedback where some folks were hoping to use this API to do large background uploads. Adding a limit would prevent this kind of abuse of the API. What is a decent limit?

Why is it the spec's responsibility to set a limit? Shouldn't this be up to the website developer to decide what is reasonable? A W3C spec just isn't the right place to try to limit the functionality of the web in the name of safety.

I think it makes sense that browser implementations have limits. But implementation-specific variability can change as needed over time. Specs can't be changed as easily.

Could we add a method for scripts to ask what the implementation limits are (both size and frequency)? We're using query strings to send data in certain places, and figuring out what will fit into query strings is annoying.

Thanks!