- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 30 Oct 2013 14:24:57 -0700
- To: Chase Douglas <chase@newrelic.com>
- Cc: Jatinder Mann <jmann@microsoft.com>, Ilya Grigorik <igrigorik@google.com>, public-web-perf <public-web-perf@w3.org>
On Wed, Oct 30, 2013 at 12:04 PM, Chase Douglas <chase@newrelic.com> wrote: > On Wed, Oct 30, 2013 at 11:36 AM, Jatinder Mann <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'm sorry but this is just plain wrong. It would be gravely irresponsible of us to create a spec which doesn't take security into consideration. If a spec can't be implemented without sacrificing user or server security then it's just a plain bad spec. Implementations won't be willing to use a lot of bandwidth after the user has left the page. A key part of the security model of the web is "it's safe to go to any page. If it uses up too much system resources, simply leave it". If pages could do tons of uploads after you leave the page then we break that security model. The only way to enable that would be to use prompting "this page wants to run in the background", and that's clearly not something we want to force upon all Beacon users. I agree that background uploads is an interesting use case, but the security model is different enough that it's better handled separately. For larger uploads you also want to handle things like resuming uploads that failed partway through, which plain HTTP can't handle. So for the foreseeable future you need to have application-specific logic anyway. > 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. If the limits aren't specified it means that authors won't be able to depend on what works and what doesn't work. Being able to depend on such things is the whole point of having an API. Asking authors to remember to check what the limits are of the specific browser/user seems bound to lead to bugs. The usecase here isn't generic background uploads. The usecase here is being able to send signals to the server in a way that is low cost to the user (in terms of bandwidth and battery). That usecase we can solve with a much simpler API than would be required to support larger uploads. / Jonas
Received on Wednesday, 30 October 2013 21:25:59 UTC