Re: How to make SimpleURLLoader (or other loader) drop requests when network change

[Ming-Ying Chung]

(+net-dev -network-dev wrong list)

On Tue, Sep 6, 2022 at 12:36 PM Ming-Ying Chung <my...@chromium.org> wrote:

Hi network teams,

Context:

We are implementing a new unload beacon API (explainer): in short, developers can create and queue beacons on a page. The beacons will be sent out by browser sometimes later either after specified time or when the page is discarded/in bfcache.

One privacy requirement we'd like to address is that beacons shouldn't be sent to a different network when users think that they have left the page (either by closing the page or navigating away).

Right now, beacon requests are constructed in the browser process, and get passed into SImpleURLLoader for sending. However, even if we do our best to listen to OnNetworkChanged() right before calling SImpleURLLoader, at worst network change can still happen within the loader, right before it sends out the request. Example scenario:

1. user is on network1

2. user navigates to site1.com, which queues beacon1

3. user close site1.com

4. the browser process observes no network change happens

5. (In browser, SimpleURLLoader is about to send out beacon1) user switches to network2.

Question:

1. Is there a way to make SimpleURLLoader (or any other loader) drop requests when the network changes? Or do we have to implement our own loader?

2. It looks like the Reporting API has similar requirements. But they seem to implement the entire //net level stuff. Do they solve this issue?

Thanks,

Ming

[Kentaro Hara]

Thanks Ming-Ying for starting the thread!

One random thought: I'm not sure if there is a way to avoid the race completely. Even if we implement everything in the net layer, the race will still happen. There is a delay between when the user switches network on Android and when Chrome responds to the network change event sent from the Android OS.

--
You received this message because you are subscribed to the Google Groups "bfcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CAH3JASWwyJpdPzLECZ-Skf%2BW-3mgAZokT4a9503hgXmgse3aOg%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Fergal Daly]

[+iclelland]

It seems like Reporting API would have this race too. Hitting it would require that the first attempt to send the report fails, then the user navigates away from the page before the resend. In that case, the resend could race with a network change,

F

[Adam Rice]

A theoretical solution would be to bind the request to the network. Cronet can do this, but only on Android. The code paths have never been exercised in Chrome itself.

Since changing networks is quite a slow operation, it might not be too bad to ignore the race condition.

You received this message because you are subscribed to the Google Groups "blink-network-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-network-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-network-dev/CAAozHLmp8ksKGJMYa1n9QGSNQywvHy4AkjGESq%3DW-70iXT4eeQ%40mail.gmail.com.