W3C home > Mailing lists > Public > public-web-perf@w3.org > June 2014

Re: [Beacon] Off-line behavior, captive portals and error recovery

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 3 Jun 2014 12:12:10 -0700
Message-ID: <CA+c2ei8j64=ttznAHisHdwbdpPjgEvBi85tmLH=tSgZ8TMeoxA@mail.gmail.com>
To: Arvind Jain <arvind@google.com>
Cc: (wrong string) „ski <kornel@geekhood.net>, public-web-perf <public-web-perf@w3.org>
On Tue, Jun 3, 2014 at 11:05 AM, Arvind Jain <arvind@google.com> wrote:
> Seems like there is agreement re. 401. The current draft will make the
> request fail if 401 authorization is required:
> https://w3c.github.io/web-performance/specs/Beacon/Overview.html
>
> I have a few more questions:
> 1) Re. 407, what should be the behavior? If the beacon response is a 407,
> should we display an authentication dialog given that the site may have gone
> away? Anne asked whether there should be a flag for it in fetching layer.
> What are we doing today in Mozilla's implementation?

I don't know. I'd lean towards saying that proxy handling is a UA
problem and we should leave it up to them.

I would think that proxy login prompts often don't have much context
anyway if the proxy is a general web proxy and not tied to a
particular website.

Also note that I believe we ignore 407 responses unless we explicitly
connected to a proxy.

> 2) Does Mozilla's current implementation persist beacons across restarts?

No.

> 3) Does Mozilla's current implementation has a limit on size of the send
> queue? Jonas seemed to suggest there isn't but I want to double check.

I think we don't really have a send queue yet. I.e. we attempt to send
the request more or less right away, and if it fails we drop it.

> 4) Does Mozilla's current implementation have a timer after which the beacon
> is dropped?

No.

/ Jonas
Received on Tuesday, 3 June 2014 19:13:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:38 UTC