On Fri, Jul 25, 2014 at 11:21 AM, ttuttle <ttuttle@chromium.org> wrote: > 3. 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. >> >> >> >> Aaron: 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. >> > > Hmm, I see your point. I'll see if we can do without retries, or postpone > them until the next time we would've made a new upload anyway. > Mirroring the language in Beacon, can we defer this decision to the UA? "The User Agent SHOULD make a best effort attempt to eventually transmit the data." It seems reasonable to allow the UA to both delay and attempt to retransmit. ig
Received on Monday, 28 July 2014 18:20:32 UTC