- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 3 Jun 2014 12:12:10 -0700
- To: Arvind Jain <arvind@google.com>
- Cc: Ilya Grigorik <igrigorik@google.com>, Kornel Lesinski <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