Re: Navigation Error Logging spec update

I've added the sentence to the draft about not retrying if error reporting
itself fails.


On Wed, Dec 11, 2013 at 11:35 AM, Reitbauer, Alois <
Alois.Reitbauer@compuware.com> wrote:

>  I agree, we should not retry. The main idea is to inform the logging
> infrastructure in real time of problems. In case your logging is down, this
> will not work anyways.
>
>
>  // Alois
>
>
>  Alois Reitbauer | Technical Product Manager | Compuware APM
>
>
>  ------------------------------
> *From:* Arvind Jain <arvind@google.com>
> *Sent:* Tuesday, December 10, 2013 3:03 AM
> *To:* Aaron Heady (BING AVAILABILITY)
> *Cc:* public-web-perf
>
> *Subject:* Re: Navigation Error Logging spec update
>
>  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
>>
>>
>>
>
>   The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
> disclose it to anyone else. If you received it in error please notify us
> immediately and then destroy it. Compuware Austria GmbH (registration
> number FN 91482h) is a company registered in Vienna whose registered office
> is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.
>