Ambiguity on "maximum data size" limit and enforcement #38
Description
The user agent should restrict the maximum data size to ensure that beacon requests are able to complete quickly and in a timely manner.
The sendBeacon method returns true if the user agent is able to successfully queue the data for transfer. Otherwise it returns false.
(note) If the user agent limits the amount of data that can be queued to be sent using this API and the size of data causes that limit to be exceeded, this method returns false. A return value of true implies the browser has queued the data for transfer.
As of today, the spec does not specify a specific maximum data size limit. This was an intentional decision when we were iterating on the early drafts; we wanted to allow UA's to experiment and adjust the limits in the future as needed. Fast forward a few years...
- Edge and Firefox enforce a 64KB limit per beacon.
- Chrome enforces a 64KB quota across all beacon-initiated requests within same nav context.
Technically, all implementations are "spec compliant", because we did not spell out the limit or exact conditions for how it should be enforced. However, the differences are also causing failures in Chrome for the proposed web-platform-tests: web-platform-tests/wpt#4024 (comment). Some thoughts and options...
a) I don't think we should spec a hard limit; I think it still makes sense to allow UAs to adjust this if and when needed. However, as a matter of general guidance to developers, I think we probably should add a non-normative note in the doc indicating that multiple browsers picked 64KB for their initial implementation.
b) Given that we don't spec a hard limit, I don't think web-platform-tests should hardcode 64KB either. It's good to have tests for "super large payloads are not allowed", but perhaps we can just change that number to something much larger in our tests.. e.g. >=1MB. That way, if an existing implementation decides to increase their limit, they're not immediately greeted with a bunch of test failures.
c) sendBeacon adoption has been growing steadily in Chrome, and our telemetry for quota exceeded shows that very few pages hit the 64KB quota; I've not heard developer complaints about it, so far, at least.. As such, I'm inclined to say that this behavior shouldn't be treated as a test failure either. It may be the case that it's a bit too restrictive (e.g. SPA app that sticks around for hours~days and uses sendBeacon under the hood), and we might want to revisit this behavior in the future (e.g. by raising the quota limit; only apply the quota requirement for beacons that fire when queued when the page is onloading; switch to same per-beacon enforcement as Edge/FF; ...), but I think it's a reasonable implementation under current spec language and should be allowed.. unless we can point to specific cases where it breaks. My proposal for this one is:
- Add a note in the spec documenting the differences in implementation
- Update submitted tests and split them into separate files to allow Chrome to pass
Additional notes and related discussions: