Re: Navigation Error Logging spec update

I want to correlate with requests while still in the browser context doing
javascript stuff, not from the server side.


On Wed, Dec 11, 2013 at 2:16 PM, Aaron Heady (BING AVAILABILITY) <
aheady@microsoft.com> wrote:

>  The timestamp on the navigation error logs should be sequential. If your
> server logs are sequential, it ought to be possible to correlate, depending
> on how much data mining you want to do.
>
>
>
> We tend to use a unique identifier per URL to help reduce this problem.
> Not on every page, but on everything you might want to be able to clearly
> correlate logs with, or across systems.
>
>
>
>
>
>
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html
> startTime attribute
>
> The startTime attribute MUST return a DOMTimeStamp<http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp>with the time immediately after the user agent finishes prompting
> to unload<http://www.w3.org/TR/html5/browsers.html#prompt-to-unload-a-document>the previous document while
> navigating <http://www.w3.org/TR/html5/browsers.html#navigate> to the
> document that resulted in an error.
>
> And
>
>
> 4.4 Monotonic Clock
>
> The value of the timing attributes must monotonically increase to ensure
> timing attributes are not skewed by adjustments to the system clock while
> recording error data. The difference between any two chronologically
> recorded timing attributes must never be negative.
>
>
>
>
>
> Aaron
>
>
>
>
>
>
>
> *From:* Chase Douglas [mailto:chase@newrelic.com]
> *Sent:* Wednesday, December 11, 2013 10:47 AM
> *To:* Arvind Jain
> *Cc:* Aaron Heady (BING AVAILABILITY); public-web-perf
>
> *Subject:* Re: Navigation Error Logging spec update
>
>
>
> One thing I've noticed in the timeline specs, so not just this spec, is
> that it is not easy to match up a timeline event entry with a specific
> request. If I hit the same endpoint twice, but one time it errors with one
> reason, and the other time it errors for a different reason, I don't really
> know which failed why unless I track the chronologic order of requests. Has
> there been any discussion about this issue?
>
>
>
> On Mon, Dec 9, 2013 at 6:03 PM, Arvind Jain <arvind@google.com> wrote:
>
>  I think we should not retry the logging fetch. I hope that addresses the
> DDOS issue.
>
>
>
> Arvind
>
>
>
> On Mon, Dec 9, 2013 at 10:06 AM, Aaron Heady (BING AVAILABILITY) <
> aheady@microsoft.com> wrote:
>
>  At some point we discussed how the UA should behave if it is a private
> browsing session. It should likely not log anything. Does that need to be
> alluded to in 5 Privacy and Security?
>
>
>
> Looking at *enableNavigationErrorReporting. *This looks like it could
> spiral out of control if both the content origin and the logging origin is
> host on the same architecture. For example:
>
>
>
> A request to http://example.com results in a HTTP 500 because of a bug on
> the origin when it is under too much load (DDOS, internal capacity issue,
> etc). The UA formats a NavigationErrorEntry and prepares to send it to
> http://example.com/logging. That in turn results in a 500 error, and
> increases the load on the origin.
>
>
>
> Should there be some back off logic? If a logging fetch fails, don’t try
> again for n*2 seconds, doubling as it continues to fail. If a logging fetch
> fails, does it retry? That is getting into the beacon logic, but it seems
> like if we are going to allow some global set of UA’s to automatically send
> logging fetches during errors, then we need some idea to limit how much
> further impact they could cause, or it is DDOS waiting to happen.
>
>
>
> Aaron
>
>
>
>
>
> *From:* Arvind Jain [mailto:arvind@google.com]
> *Sent:* Sunday, December 8, 2013 11:32 AM
> *To:* public-web-perf
> *Subject:* Re: Navigation Error Logging spec update
>
>
>
> Checking in.
>
>
>
> Do folks have any comments on the draft?
>
>
>
> Arvind
>
>
>
> On Fri, Nov 29, 2013 at 6:25 PM, Arvind Jain <arvind@google.com> wrote:
>
>  I added two methods to the interface to allow reporting of errors in
> real time to a report url as per *ACTION-117 -* *Add method to allow
> ability to send to a third party url.*
>
>
>
>
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html
>
>
>
> Please review and let me know if you have any concerns.
>
>
>
> Arvind
>
>
>
>
>
>
>