Best effort attempt to transmit the error

[igrigorik]

From: http://lists.w3.org/Archives/Public/public-web-perf/2014Jul/0095.html

ttuttle@: I'd like to allow the user-agent to retry the uploads if they fail. If the issue is a transient network issue (i.e. a route is flapping), it's a waste to throw out the error report just because the network was still glitched the first time the upload was attempted.

aheady@: This reads like a denial of service attack. We did discuss it originally, but how do you control the retries when an origin has a short lived but widespread spike in errors, especially when the origin for the error is also the origin/logging endpoint for these navigation error calls. A few seconds after it recovers it gets hit with a global surge in telemetry request, knocking if offline, more errors…... Also goes back to #1, any error that is stable enough to repro is going to be reported by a large number of users. I expect this system to be lossy telemetry wise. Optimized to protect the origin, not the error telemetry. And if you wait for the next successful page load, then you can get the errors from the queue.

Mirroring the language in Beacon, I think we can (read, should) defer this decision to the UA:
"The User Agent SHOULD make a best effort attempt to eventually transmit the data."

Above reserves the right to retry, but it does not imply that it must be implemented.

[igrigorik]

• consider starting with single report URL, but have some provisions for multiple report URLs?

[igrigorik]

Resolved in new draft, closing.