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

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?
2) Does Mozilla's current implementation persist beacons across restarts?
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.
4) Does Mozilla's current implementation have a timer after which the
beacon is dropped?




On Tue, May 20, 2014 at 11:07 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, May 19, 2014 at 11:07 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> >
> > On Fri, May 16, 2014 at 4:50 PM, Kornel Lesiński <kornel@geekhood.net>
> > wrote:
> >>
> >> - HTTP 305 Use Proxy, 401 Unauthorized, and 407 Proxy Authentication
> >> Required should be treated transparently as for any other subresource.
>
> For 401s I think we should simply make the request fail. If the user
> has already left the page that sends the beacon, the browser isn't
> going to want to open a username/password dialog for the old page.
> That could too easily confuse the user into entering the wrong
> username/password. Consider the following:
>
> 1. User goes to evilwebsite.com
> 2. evilwebsite.com sends a beacon to evilwebsite.com/gotyerpasswd
> 3. evilwebsite.com sets window.location="bank.com"
> 4. evilwebsite.com/gotyerpasswd waits 10 seconds before doing anything
> else
> 5. User sees bank.com
> 6. evilwebsite.com/gotyerpasswd sends a 401 response
> 7. Browser displays authentication UI on top of bank.com
>
> We don't want step 7 to happen because there's a very large risk that
> the user will enter his bank username/password into the dialog, which
> would cause the username/password to be sent to evilwebsite.com.
>
> We could still put up the authentication dialog if the user hasn't
> left the website yet, however given that one of the main usecases of
> sendBeacon is to send data as the user is leaving the page, that
> doesn't seem worth optimizing for.
>
> Especially given that it would introduce a race condition where the
> authentication dialog may or may not come up depending on how fast the
> server is that received the beacon, when the user navigates, and how
> quickly the navigated-to website responds.
>
> So I think we should specify that 401 responses should always be
> treated as a permanent error.
>
> The rest of the list seemed reasonable to me except for the
> captive-portal one which I don't really have an opinion on.
>
> A more tricky subject is offline though. I personally would prefer if
> the UA queued any requests that were scheduled when the user is
> offline and then return false. Up to some queueing limit of course, at
> which point the UA should return false from sendBeacon.
>
> So far we've decided to leave UA-limits unspecified and I see no
> reason to do something else here.
>
> However I believe that we elsewhere have talked about simply pushing
> the responsibility of offline onto apps and always having the UA make
> sendBeacon return false whenever the user is offline. But I would
> prefer to not do that, although that is what the current Gecko
> implementation does I believe.
>
> / Jonas
>