Re: Proposing changes to Navigation Error Logging

Hi all. I've opened a few bugs to track the discussion in this thread:

- Reporting multiple errors: https://github.com/w3c/error-logging/issues/1
- Best effort attempt to transmit the error:
https://github.com/w3c/error-logging/issues/2
- Error logging for subresources:
https://github.com/w3c/error-logging/issues/3
- startTimeUTC is insufficient due to client's clock skew:
https://github.com/w3c/error-logging/issues/4

Let's hash these out on GitHub and get them resolved... We (Chrome) are
interested in pushing forward with implementation, but currently blocked on
the spec.

ig

On Mon, Jul 28, 2014 at 11:19 AM, Ilya Grigorik <igrigorik@google.com>
wrote:

>
> 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
>